English | 简体中文

cloudtty is an easy-to-use operator to run web terminal and cloud shell intended for a kubernetes-native environment. You can easily open a terminal on your own browser via cloudtty. The community is always open for any contributor and those who want to have a try.

Literally, cloudtty herein refers to a virtual console, shell, or terminal running on web and clouds. You can use it anywhere with an internet conneciton and it will be automatically connected to the cloud.

Early user terminals connected to computers were electromechanical teleprinters or teletypewriters (TeleTYpewriter, TTY), which might be the origin of TTY. Gradually, TTY has continued to be used as the name for a text-only console although now this text-only console is a virtual console not a physical console.

A project ttyd provides some features to share terminals over the web. But if you use Kubernetes, a more cloud-native enviroment is required to run the webtty via the kubernetes way (running as a pod, and generated by CRDs), which is covered by cloudtty. You are welcome to try cloudtty 🎉.

1. Many enterprises use a cloud platform to manage Kubernetes, but due to security reasons, you cannot use SSH to connect the node host to execute kubectl commands. In this case, you may require a cloud shell capability.

2. A running container on kubernetes can be "entered" (via Kubectl exec) on a browser web page.

3. The container logs can be displayed in real time (scrolling) on a browser web page.

After the cloudtty is intergated to your own UI, it would look like:

• Step 1: Install the Operator and CRDs

  a. Install the operator using Helm

  helm repo add daocloud https://release.daocloud.io/chartrepo/cloudshell
  helm install cloudtty-operator --version 0.4.0 daocloud/cloudtty

  b. Wait for the operator pod until it is running

  kubectl wait deployment  cloudtty-operator-controller-manager   --for=condition=Available=True

• Step 2: Create a cloudtty instance by applying CR, and then monitor its status

  kubectl apply -f https://raw.githubusercontent.com/cloudtty/cloudtty/v0.4.0/config/samples/local_cluster_v1alpha1_cloudshell.yaml

  By default, it will create a cloudtty pod and expose the NodePort service. Alternatively, Cluster-IP, Ingress, and Virtual Service(for Istio) are all supported as exposureMode, please refer to config/samples/ for more examples.

• Step 3: Observe CR status to obtain its web access url, such as:

  kubectl get cloudshell -w

  You can see the following information:

  NAME                 USER   COMMAND  TYPE        URL                 PHASE   AGE
  cloudshell-sample    root   bash     NodePort    192.168.4.1:30167   Ready   31s
  cloudshell-sample2   root   bash     NodePort    192.168.4.1:30385   Ready   9s

  When the status of cloudshell changes to Ready and the URL field appears, copy and paste the URL on your browser to access the cluster with kubectl, as shown below:

  

Most users need more than just the basic kubectl tools to manage their clusters. we can customize image based on cloudshell base image. here is an example of adding the karmadactl tool.

• Modify .

FROM ghcr.io/cloudtty/cloudshell:v0.4.0

RUN curl -fsSLO https://github.com/karmada-io/karmada/releases/download/v1.2.0/kubectl-karmada-linux-amd64.tgz \
    && tar -zxf kubectl-karmada-linux-amd64.tgz \
    && chmod +x kubectl-karmada \
    && mv kubectl-karmada /usr/local/bin/kubectl-karmada \
    && which kubectl-karmada

ENTRYPOINT ttyd

• Rebuild new image with karmadactl tool：

docker build -t <IMAGE> . -f docker/Dockerfile-webtty

There are two way to set customized cloudshell image:

1. we can set image directly by cloudshell CR field spec.image.

apiVersion: cloudshell.cloudtty.io/v1alpha1
kind: CloudShell
metadata:
  name: cloudshell-sample
spec:
  configmapName: "my-kubeconfig"
  image: ghcr.io/cloudtty/customize_cloudshell:latest

2. set the 'JobTemplate' image parameter to run customized cloudshell image when installing cloudtty.

helm install cloudtty-operator --version 0.4.0 daocloud/cloudtty --set jobTemplate.image.registry=</REGISTRY> --set jobTemplate.image.repository=</REPOSITORY> --set jobTemplate.image.tag=</TAG>

If you have installed cloudtty, you can also modify the configMap of JobTemplate to set the cloudshell image.

If cloudtty manages a remote cluster (another cluster than which the cloudtty operator runs on), you need tell cloudtty the kube.conf of the remote cluster as below.

You can copy the kube.config ~/.kube/config from a remote cluster.

kubectl create configmap my-kubeconfig --from-file=kube.config

Be careful to ensure the /root/.kube/config:

1. contains the base64 encoded certs/secrets instead of local files.

2. can reach the k8s api-server endpoint (via host IP or cluster IP) instead of localhost.

• If the cluster is remote, cloudtty needs to specify kubeconfig to access the cluster using the kubectl command tool. You need to provide the kubeconfig stored in configmap and specify the name to cloudshell spec.configmapName CR. kubeconfig will be automatically mounted to the cloudtty container. Ensure that the server IP address is properly connected to the cluster network.

• If cloudtty runs on the same cluster which to be managed, you don't need to do this (a ServiceAccount with cluster-admin role permissions will be binded to the pod automaticlly. Inside the container, kubectl automatically detects CA certificates and token. If any concern with security, you can also provide your own kubeconfig to control the permissions for different users.)

The basic image to cloudshell had integrated plugin of , we can use its command to connect a arbitrary node of specified cluster. it will running a pod with privilege, if you attach importance to pod security, please be careful with the feature. see following sample:

apiVersion: cloudshell.cloudtty.io/v1alpha1
kind: CloudShell
metadata:
  name: cloudshell-node-shell
spec:
  configmapName: "<KUBECONFIg>"
  commandAction: "kubectl node-shell <NODE_NAME>"

More sample to

If cluster had existed security policy such as PodSecurity and PSP, the feature may be affected.

Cloudtty provides the following four modes to expose cloudtty services to satisfy different usage scenarios:

• ClusterIP: Service ClusterIP type in a cluster, which is suitable for third-party integration of cloudtty server. You can choose a more flexible way to expose your services.

• NodePort (default): The simplest way to expose the service mode is to create a service resource with type NodePort in a cluster. You can access the cloudtty service using the master node IP address and port number.

• Ingress: Create a Service resource of ClusterIP type in a cluster and create an ingress resource to load the service based on routing rules. This works when the Ingress Controller is used for traffic load in the cluster.

• VirtualService (Istio): Create a ClusterIP Service resource in a cluster and create a VirtaulService resource. This mode is used when Istio is used to load traffic in a cluster.

• AllowSecretStoreKubeconfig：restore kubeconfig file with secret resource, if open the featureGate, the field spec.configmapName will be disable, we can use field spec.secretRef.name to difine kubeconfig where are. currently the featureGate is alpha pahse, disabled by default.

1. If use the way to yaml to deploy cloudtty, add --feature-gates=AllowSecretStoreKubeconfig=true to operator running args.
2. If use the way to helm to deploy cloudtty, we can set the params --set image.featureGates.AllowSecretStoreKubeconfig=true.

1. Operator creates a job and a service with the same name in the proper namespace. If Ingress or VitualService is used, it also creates the routing information.

2. When the pod status is Ready, it will show the access url to the cloudshell status.

3. When a job ends after the TTL is expired or the job is terminated for some other reasons, the cloudshell status changes to Completed once the job changes to Completed. You can set cloudshell to delete associated resources when the status is Completed.

4. When cloudshell is deleted, the corresponding job and service (through 'ownerReference') are automatically deleted. If Ingress or VitualService mode is used, the corresponding routing information will be deleted too.

1. Generate CRDs to charts/_crds

make generate-yaml

2. Install CRDs

make install

3. Run the operator

make run

For example, automatically print logs for a container.

apiVersion: cloudshell.cloudtty.io/v1alpha1
kind: CloudShell
metadata:
  name: cloudshell-sample
spec:
  configmapName: "my-kubeconfig"
  runAsUser: "root"
  commandAction: "kubectl -n kube-system logs -f kube-apiserver-cn-stack"
  once: false

This project is based on https://github.com/tsl0922/ttyd. Many thanks to tsl0922, yudai, and the community. The frontend UI code was originated from ttyd project, and the ttyd binary inside the container also comes from ttyd project.

If you have any question, feel free to reach out to us in the following ways:

• Slack Channel

• WeChat Group: contact calvin0327(wen.chen@daocloud.io) to join

• Control permissions through RBAC (to generate the /var/run/secret file).

• For security, jobs should run in separate namespaces, not in the namespace same as cloudshell.

• Check the pod is running and endpoint status changes to Ready, and the cloudshell phase is set to Ready.

• TTL should be set to both job and shell.

• Job creation templates are currently hardcode and should provide a more flexible way to modify the job template.

More will be coming Soon. Welcome to open an issue and propose a PR. 🎉🎉🎉

Made with contrib.rocks.