Kubernetes CRD Magic: Embedding Terminals Directly on Your Webpage
Tags: kubernetes, docker, containers, cloud
Published: 2023-09-04 07:44:26

In the realm of Kubernetes, utilities such as `kubectl` and `helm` serve as our principal conduits for cluster interaction. Yet, occasions arise when one might desire to instantiate a terminal directly on a webpage, bypassing the need to embed and configure these instruments locally. This treatise plunges into the intricate details of **procuring this capability via Kubernetes Custom Resource Definitions (CRD)**, elucidating its architectural and practical facets through a tangible illustration.

![](https://cdn.jsdelivr.us/gh/yangchuansheng/imghosting5@main/uPic/2023-08-04-10-17-ZG0cj9.jpg)

The App Launchpad and Database suites within [Sealos](https://sealos.io) have distilled the Kubernetes resource layer's intricacies into the application stratum. Nonetheless, for more multifaceted situations, a more innate interaction with Kubernetes becomes essential.

Outlined below is the engagement with the K8s API Server via the Terminal:

Assessing Pod assets (Kubernetes' elemental scheduling unit, housing the actual container resources):

```bash
$ kubectl get pod
```

![](https://cdn.jsdelivr.us/gh/yangchuansheng/imghosting5@main/uPic/2023-08-04-10-18-XjO8Vt.jpg)

Surveying storage pvc resources (container-mounted storage assets, akin to those delineated in App Launchpad):

```bash
$ kubectl get pvc
```

![](https://cdn.jsdelivr.us/gh/yangchuansheng/imghosting5@main/uPic/2023-08-04-10-18-79QKjD.jpg)

## Advanced Terminal Endeavors

The Terminal facilitates a plethora of sophisticated tasks.

### Seamless Integration of Terminal & App Launchpad

Direct entry into each application container's terminal is achievable through the terminal app. Imagine deploying an entity like Nginx under application governance. Navigate to Nginx application's detailed interface, select the ellipsis on the detailed section's rightmost edge, and upon choosing 'Terminal', one is ushered into the Nginx application's terminal.

![](https://cdn.jsdelivr.us/gh/yangchuansheng/imghosting-test@main/uPic/2023-09-04-11-31-fqpgrE.png)

![](https://cdn.jsdelivr.us/gh/yangchuansheng/imghosting-test@main/uPic/2023-09-04-11-33-8u45H9.png)

### Unhindered Bridging of Terminal & Database

Establish an immediate linkage with the database, orchestrated in the [Database App](https://docs.sealos.io/docs/platform-components/dbprovider/), right from the terminal.

Transition to the database's comprehensive view, and opt for the 'connect' to the left, Transition seamlessly to the Terminal and establish a direct connection with the database.

![](https://cdn.jsdelivr.us/gh/yangchuansheng/imghosting-test@main/uPic/2023-09-04-11-25-AP2rs3.jpg)

## Feature Dissection

This capability's nucleus is a Kubernetes CRD christened `Terminal`. End-users can inaugurate a novel `Terminal` CRD on the webpage, post which a new Terminal materializes. This Terminal possesses rights to the designated Kubernetes Namespace, enabling execution of commands such as `kubectl` and `helm`.

Here's an archetype of a `Terminal` CRD:

```yaml
spec:
  apiServer: https://kubernetes.default.svc.cluster.local:443
  ingressType: nginx
  keepalived: 4h
  replicas: 1
  token: xxxxx
status:
  availableReplicas: 1
  domain: https://xxxxxx.cloud.sealos.io
```

### CRD Field Analysis

Within the `spec` segment of the `Terminal` CRD, each field is delineated as:

- `apiServer`: Kubernetes API server's nexus. Employed by the Terminal for liaisons with the Kubernetes API.
- `ingressType`: Ingress controller variety, either `nginx` or `apisix`.
- `keepalived`: Terminal's duration. For instance, `4h` denotes an automatic dissolution of the Terminal 4 hours post-inception.
- `replicas`: The Terminal's replication count. Presently, only a solitary replica is endorsed.
- `token`: Authentication token for the Kubernetes API server, harnessed for Terminal's authentication.

The `status` portion dissects each domain as:

- `availableReplicas`: The tally of available replications.
- `domain`: The nexus employed for web-based Terminal interactions.

Upon the `Terminal` CRD's origination, a fresh Terminal manifests on the webpage. Users are equipped to run commands like `kubectl` and `helm` within this Terminal.

## Architectural Blueprint & Execution

The `Terminal` feature's blueprint and realization comprise several pivotal elements:

### Terminal Steward

The `Terminal` Steward stands as the linchpin of the `Terminal` functionality, vigilantly overseeing the genesis, modification, and dissolution events of the `Terminal` CRD and adapting in response.

### Terminal Capsule

The `Terminal` Capsule epitomizes the live Terminal, hosting a bespoke Docker image laden with command-line apparatuses like `kubectl` and `helm`, alongside a web terminal server, such as [ttyd](https://github.com/tsl0922/ttyd). The embedded web terminal server hearkens to port 8080, delivering web terminal services.

### Service & Gateway

Every `Terminal` CRD sees the `Terminal` Steward instituting a corresponding Kubernetes Service and Gateway. The Service channels traffic to the `Terminal` Capsule, while the Gateway navigates external access petitions to the Service.

### Terminal Docker Imagery

The Docker imagery for the `Terminal` Capsule, founded on Ubuntu 20.04, is embellished with command-line tools including `kubectl`, `helm`, and the ttyd web terminal server. Moreover, it is augmented with MySQL, MongoDB, and Redis clients, facilitating users to connect and govern these databases directly within the Terminal.

The image's fabrication sequence unfolds as:

1. Integrate vital software packages, spanning `kubectl`, `helm`, `vim`, and beyond.
2. Implant the web terminal server `ttyd` and an initialization script `start-terminal.sh`.
3. Designate the `ttyd` server to port 8080 and calibrate its initiation parameters, which encompass the Kubernetes API server nexus and access token.

### Terminal's Dissolution & Longevity

The `Terminal` Steward wields Kubernetes' Finalizer mechanism to address the `Terminal` CRD's termination events. As a `Terminal` CRD meets its end, the Finalizer postpones Kubernetes from immediate eradication, holding out for the `Terminal` Steward to clear out resources tied to the `Terminal` CRD (like Deployment, Service, and Gateway) before the CRD's removal.

Furthermore, the `Terminal` Steward capitalizes on the Keepalive mechanism, autonomously eliminating lapsed `Terminal` entities. The `Terminal` longevity, designated by the `keepalived` field, triggers its erasure once its existence surpasses the stipulated `keepalived` duration.

## Interaction Schema Between the User Interface and Backend Systems

Outlined below is the meticulous progression from the moment a user engages the Terminal button to when they gain access to the Terminal:

1. Users activate the Terminal button on a web interface, instigating a backend request. This petition encompasses details regarding the Terminal's configuration, such as its designated Kubernetes Namespace and predetermined lifespan.

2. Upon assimilation of the request, the backend system spawns a novel `Terminal` CRD (Custom Resource Definition) infused with the Terminal's specific configuration attributes.

3. The vigilant `Terminal` Controller, upon discerning the genesis of a new `Terminal` CRD, orchestrates the appropriate `Terminal` Pod. This specific Pod operates a Docker image replete with command-line tools like `kubectl`, `helm`, and an embedded web terminal server.

4. Concurrently, the `Terminal` Controller commissions a corresponding Kubernetes Service and Ingress. This Service navigates network traffic towards the `Terminal` Pod, whilst the Ingress directs external solicitations to the said Service.

5. Posthaste, the backend system extracts the Terminal's domain information from the `status` segment of the `Terminal` CRD, relaying this domain to the frontend system.

6. Upon reception of the Terminal's domain, the frontend system projects it onto a fresh browser tab, furnishing users with a pristine Terminal. Within this environment, users are equipped to invoke commands such as `kubectl`, `helm`, and more.

## Tailored Configurations

### Assorted Ingress Controller Compatibility

The `Terminal` is adept at liaising with a plethora of Ingress Controllers, notably Nginx and Apisix. Users are thus empowered to elect an Ingress Controller that resonates with their distinct requirements.

### Adjustable Lifespan Setting

End-users possess the prerogative to delineate the Terminal's duration of existence. Post a specified interval subsequent to its creation, the `Terminal` will be autonomously terminated. This strategy circumvents the undue occupation of resources by dormant Terminals.

## Prospective Enhancements

### Augmented Command-line Instrument Integration

Anticipated versions shall incorporate an expansive set of command-line tools within the `Terminal` Docker image, encompassing tools like `istioctl`, `kn`, and beyond, bestowing users with a more extensive operational gamut.

### Expanded Ingress Controller Affiliation

There are blueprints to embrace supplementary Ingress Controllers such as Traefik and HAProxy, thereby diversifying users' available choices.

### WebSocket Channelization

The inauguration of a WebSocket service through Ingress is cardinal. This facilitates users to inaugurate a terminal within the web facade and liaise with the Kubernetes cluster via WebSockets. When juxtaposed against HTTP, WebSockets proffer a superior real-time bi-directional communication channel, amplifying user engagement.

### Granulated Access Governance

The incorporation of a refined access governance mechanism is paramount. With imminent enterprise collaborative modules, a myriad of users could coalesce within namespaces. Consequently, the terminal will access distinct user realms—be it managerial or developmental—relying on the permissions procured.

### Assimilation of Diverse Development Apparatuses

Beyond the realms of `kubectl` and `helm`, the Terminal aspires to amalgamate a variety of developmental and debugging tools, including but not limited to `git`, `curl`, `jq`, and so forth.

### User-Centric Customizations

End-users will be capacitated to modify the Terminal's visual aesthetics, such as chromatic themes, typographic dimensions, and more. Additionally, they can calibrate behavioral configurations like the archival depth of command histories, tactile shortcuts, among others.

## Epilogue

Leveraging Kubernetes' CRD capabilities, we can seamlessly induct a robust Terminal within a web framework. Within this Terminal, users can seamlessly deploy an array of commands, fostering a more intimate rapport with the Kubernetes cluster. This not only optimizes their procedural workflows but also profoundly elevates their overarching interaction experience.