En esta oportunidad vamos a responder a una pregunta muy frecuente de nuestros clientes. Y es ¿Como inicio sesión SSH a los nodos del cluster de Tanzu Kubernetes Grid (TKG), recientemente renombrado a vSphere Kubernetes Service (VKS)?. Pues bien, vSphere with Tanzu ahora vSphere IaaS Control Plane, esta diseñado para que no haya necesidad de tener que ingresar a estos nodos. Sin embargo, algunos clientes son curiosos y quieren acceder a darle una mirada a estos nodos.
CONTENIDO
Lo primero que debemos decir es que hay varia forma de hacerlo incluyendo una en donde nos conectamos a traves del vCenter a las Control Plane del Supervisor Cluster y desde ahi saltamos a las control VM de los TKG. Sin embargo, esta opción no parece ser la mejor para los clientes que no quiere compartir un acceso ssh al vCenter solo para poder acceder a la VMs del cluster de K8s que hemos llamado acá TKG (Tanzu Kubernetes Grid) recientemente renombrado como VKS (vSphere Kubernetes Services).
Sin mas preámbulo, te explico la forma correcta de hacerlo, basado en la documentación oficial SSH to TKG Service Cluster Nodes as the System User Using a Password aunque podemos también encontrar los pasos resumidos en el siguiente VMware KB Accessing vSphere with Tanzu workload clusters using SSH
Prerrequisito
Create a Linux Jump Host VM
Este prerrequisito es muy facil de cumplir y basicamente vamos a necesitar una VM basada en Linux. Sino tenemos una, podemos seguir la documentación oficial Create a Linux Jump Host VM para desplegar un Photon OS.
Pero si como en mi caso ya tienen una, pueden usar esa. Lo único que debemos hacer es agregarle una segunda interface, que tenga acceso a la red de Workload Network > Namespace Network del Supervisor Cluster.
Así que agrégale una segunda interface a tu VM existente o nueva y déjala hasta ahi. Mas adelante veremos cuál IP, Subnet o NSX Segment configurarle.
Identificar la Workload Network
Antes de continuar, es importante entender que los objetos de Kubernetes crean objetos en NSX
• Un Kubernetes namespace crea un logical segment.
• Un vSphere Pod crea un logical port conectado al logical segment.
• Kubernetes crea un correspondiente virtual server en NSX para su servicio load balancer.
Para saber cual es la red de Workload Network, vamos a ver la configuración de Supervisor Cluster en Workload Management > Supervisors > [Supervisor-Name] > Network > Workload Network
Nota: Aqui vemos que la Namespace Network es la 10.244.0.0/20 y es subneteada con /28 para cada Namespace (vSphere Namespace) que se crea en el Supervisor Cluster.
Ahora bien, en el NSX que soporta el despliegue de Supervisor Cluster, solo si su solucion de Supervisor fue desplegada usando NSX, vamos a ver que por cada Namespace en el Supervisor Cluster se crea un T1 Gateway y que estos tienen un sufijo que contiene el nombre de los cluster TKGs ha creado.
Y en la columna Linked Segments tenemos un numero que nos indica a cuantos segmentos NSX esta conectado. Por lo general hay mínimo dos segmentos asociados, seg-domain-xxx y un vnet-domain-yyy. Puede haber mas si el Namespace tiene mas de un cluster vSphere Pods por dentro. En este caso solo tengo un Cluster de TKG desplegado en ese vSphere Namespace. Para mas información acerca de objectos creados en NSX por favor visitar NSX Networking Objects for VKS Clusters.
Lo importante a entender aquí, es que las VM de Control y Worker de los cluster TKG esta conectados al segmento vnet-domain-yyy de esos T1 Gateways. Por lo que nuestra tarea es agregar un IP de ese Segmento a la VM Jump que teníamos disponible o que tuvimos que crear.
De lo anterior, podemos hacer el siguiente análisis. Si el segmento vnet-domain-yyy tiene configurado el gateway 10.244.0.145, la VM de control del TKG la 10.244.0.146 y la de Worker del TKG la 10.244.0.147 y ya sabemos que nuestra solución Supervisor Cluster hace subnet /28 para cada vSphere Namespace. Quiere decir aun tenemos 11 IPs de la subnet disponibles para poder asignársela a la interface de nuestra VM Jump. Solo para aclarar, recordemos que /28 no da 16 IPs disponibles y 14 IPs usables, pero aca ya tenemos 3 IPs utilizadas.
Nota: Esto puede cambiar si tiene mas componentes dentro del su vSphere Namespace, o mas nodos en sus cluster de TKG.
- En este caso, como mencionamos anteriormente, ya tenia una VM linux en el ambiente, de manera que solamente le voy a conectar una segunda interface. Si usted no tiene una siga la documentación para descarga el ISO o el OVA y desplegar el Photon OS y cuando este listo continue con este paso.
Nota: Recordemos que las IPs que ha tomado las Control VM y Worker nodes de TKG son del Segmento vnet-domain-xxxxxx-Namespace-Name-yyy. Por esta razon debemos conectar ese Segmento NSX a nuestra VM en la segunda interface.
- Configure la máquina virtual con una dirección IP desde Red de Workload > Red del Namespace.
# sudo ip addr add 10.244.0.158/28 dev ens35
# ip addr show ens35
Nota: Se recomienda utilizar para esto la ultima IP disponible de esa subnet /28 o una de las ultimas para evitar overlapping si agregamos mas recursos a ese vSphere Namespace.
- Una vez configurada la IP vamos a verificar que podemos hacer ping al gateway
Nota: En este punto ya estamos listos para iniciar sesión a nuestros TKG clusters.
Procedimiento para iniciar sesión SSH a los nodos TKG
En este punto ya deberíamos poder hacer SSH a la VM. Sin embargo. Primero debemos obtener la contraseña de esas VMs, siguiendo SSH to TKG Service Cluster Nodes as the System User Using a Password, pero como siempre acá lo vamos a resumir. Entonces lo primero es hacer login al supervisor cluster
kubectl vsphere login --server=https://<SUPERVISOR_IP> [--vsphere-username <VSPHERE_USERNAME>]
- Cambiar el contexto (vSphere Namespace) donde esta aprovisionado el clúster TKG.
kubectl config get-contexts
kubectl config use-context [vSPHERE_NAMESPACE_NAME]
Ejemplo: En este caso queremos hacer login a un TKG que esta en el vSphere Namespace `terraform-cli`
- Ahora listamos las VMs para saber cuales conforman el cluster TKG
kubectl get virtualmachines
- (Opcional) podemos ejecutar el siguiente comando para ver la IP de las VMs desde
kubectlo podriamos verla directamente en el inventario de vSphere
kubectl describe virtualmachine VM_NAME
Acá vamos a poder ver la IP configurada
Aunque podemos verla también desde el vSphere Client
- Ahora vamos a visualizar los secrets que esta configurados en este vSphere Namespace con el siguiente comando
kubectl get secrets
- De la salida anterior nos interesa obtener el Password SSH de las VM de Control y Worker del TKG cluster y para eso vamos a utilizar el siguiente comando
kubectl get secrets TKG-CLUSTER-NAME-ssh-password -o yaml
Nota: El comando anterior nos devuelve el password de ssh
Nota (solo Windows nodes): Si su TKG usa nodos Windows. Dado que los nodos Windows no permiten un mecanismo SSH basado en contraseña, utilice la Private Key para acceder por SSH a los nodos de Control y Worker. Para eso utilice el siguiente comando.
kubectl get secrets TKG-CLUSTER-NAME-ssh -o jsonpath='{.data.ssh-privatekey}
- Ahora debemos decodifica el Password SSH o Private Key segun sea el caso de nuestros nodos, Linux o Windows
Descifrar el Password SSH (Nodos basados en Linux):
El secreto está codificado en Base64. Para decodificarlo,
- En Linux use base64 –decode (o base64 -d);
- En MacOS, use base64 –decode (o base64 -D);
- En Windows, use an online tool.
Debido a que nuestro jump es Ubuntu usaremos la opcion base64 --decode
echo <ssh-passwordkey> | base64 --decode
Nota: Por alguna razon, el password decodificado no se mostro en una linea nueva, pero es esa. Si queremos comprobarlo podemos copiar el password y pegarlos en el online tool.
Descodificar la Private Key (Nodos basados en Windows)
Utilice el mismo mecanismo que utilizó para decodificar el Password SSH. Guarde la Private Key SSH decodificada en un archivo y configure los permisos chmod 400 FILE_NAME.
- Si hemos seguido las pasos hasta el momento, ya deberíamos poder iniciar sesión SSH a nuestros nodos del TGK desde nuestra Jump VM, ya sea con la Password SSH o Private Key decodificados, según corresponda (nodos linux o Windows).
Iniciamos entonces SSH a cualquiera de los nodos del clúster TKG con el usuario del sistema vmware.
Para utilizar Password SSH (nodos Linux), use este comando.
ssh vmware-system-user@TKG-CLUSTER-NODE-IP-ADDRESS
Para utilizar Private Key (nodos Windows), utilice el siguiente comando.
ssh -i filename vmware-system-user@TKG-CLUSTER-NODE-IP-ADDRESS
Nota: filename Es el archivo donde almacenaste la Private Key SSH para los nodos Windows.
Conclusion
Con este procedimiento habrá logrado iniciar sesión en los nodos de Control o Worker de su TKG cluster, utilizando el Password o Private Key que decodificó.
¡IMPORTANTE! He migrado blog del dominio nachoaprendevirtualizacion.com a nachoaprendeit.com. Si te ha servido este artículo deja tu buen Like y compártelo con tus colegas, estas aciones me ayudarán a optimizar los motores de búsqueda para llegar a más personas, y a motivarme a seguir compartiendo este tipo de artículos.
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
Now we will choose the context that has our napp deployment, which should be 
Repeat the steps for the following images that will be the gradual jumps:
Now if we run the command 
Nacho Aprende IT 