Access
This document outlines possible necessary steps to access the Kubernetes clusters. COTB distinguishes between two different clusters: the CDO and the Workload cluster.
To access Kubernetes clusters you need the cli tool kubectl and a kubeconfig.yaml file loaded by it. Please refer to the official documentation for details.
CDO
The CDO cluster fulfils the role bootstrapping every other node. It does so by leveraging the process described in tech/booting. To directly access this cluster, the following steps are necessary:
- Login to the CDO node. Refer to the inventory network and common section to figure out the connection details.
- Extract the cluster config via
sudo cat /etc/rancher/k3s/k3s.yaml - Replace the
defaultnames with something reasonable - Replace the
url:address with the correct one as listed in your inventory (typicallycdo/kubernetes/node_ip) or viakubectl get nodes -o jsonpath='{.items[?(@.metadata.name=="cdo01")].status.addresses[?(@.type=="InternalIP")].address}'
Use the resulting kubeconfig.yaml as described above.
If your cluster is not directly accessible from your client we recommend a proxy setup. Make sure to get a SSH connection to the CDO node as described in step 1 via ssh, but with the following changes:
ssh -D 6443 -q -N $SSH_USERNAME@$SSH_HOSTNAME
This creates a local SOCKS5 proxy. You can the append the key value pair proxy-url: socks5://localhost:6443 to your kubeconfig.yaml at clusters.0.cluster.proxy-url.
Full example:
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: [REDACTED]
server: https://$NODE_IP:6443
proxy-url: socks5://localhost:6443
name: $CLUSTER_NAME-cdo
contexts:
- context:
cluster: $CLUSTER_NAME-cdo
user: $CLUSTER_NAME-cdo
name: $CLUSTER_NAME-cdo
current-context: $CLUSTER_NAME-cdo
kind: Config
preferences: {}
users:
- name: $CLUSTER_NAME-cdo
user:
client-certificate-data: [REDACTED]
client-key-data: [REDACTED]
Workload
Follow the exact same routine as for the CDO, but replace the CDO hostname with your control nodes.