En las siguientes secciones se describe cómo configurar clústeres de carga de trabajo de Tanzu Kubernetes Grid (TKG) para que utilicen funciones específicas de vSphere con un clúster de administración independiente. Las funciones no se pueden configurar por completo en el archivo de configuración plano del clúster o en la especificación de objeto de estilo Kubernetes.
Para obtener información sobre cómo configurar clústeres de carga de trabajo en vSphere mediante especificaciones de objetos y archivos de configuración, consulte:
Si utiliza una sola imagen OVA personalizada para cada versión de Kubernetes con el fin de implementar clústeres en un sistema operativo, importe el archivo OVA en vSphere y, a continuación, especifíquelo para tanzu cluster create
con la opción --tkr
.
Sin embargo, si utiliza varias imágenes OVA personalizadas para la misma versión de Kubernetes, el valor --tkr
es ambiguo. Esto sucede cuando los archivos OVA para la misma versión de Kubernetes:
make build-node-ova-vsphere-ubuntu-1804
, make build-node-ova-vsphere-photon-3
ymake build-node-ova-vsphere-rhel-7
.Para resolver esta ambigüedad, establezca la opción VSPHERE_TEMPLATE
en la imagen OVA deseada antes de ejecutar tanzu cluster create
:
Si el nombre de la imagen de la plantilla de OVA es único, establezca VSPHERE_TEMPLATE
solo en el nombre de la imagen.
Si varias imágenes comparten el mismo nombre, establezca VSPHERE_TEMPLATE
en la ruta de acceso de inventario completa de la imagen en vCenter. Esta ruta sigue el formato /MY-DC/vm/MY-FOLDER-PATH/MY-IMAGE
, donde:
MY-DC
es el centro de datos que contiene la imagen de plantilla de OVA.MY-FOLDER-PATH
es la ruta de acceso a la imagen desde el centro de datos, como se muestra en la vista de Máquinas virtuales y plantillas de vCenter.MY-IMAGE
es el nombre de la imagen.Por ejemplo:
VSPHERE_TEMPLATE: "/TKG_DC/vm/TKG_IMAGES/ubuntu-2004-kube-v1.29.9-vmware.1"
Puede determinar manualmente la ruta de acceso de inventario completa de vCenter de la imagen o utilizar la CLI govc
:
govc
. Para obtener instrucciones de instalación, consulte el repositorio govmomi en GitHub.govc
acceda a vCenter:
export GOVC_USERNAME=VCENTER-USERNAME
export GOVC_PASSWORD=VCENTER-PASSWORD
export GOVC_URL=VCENTER-URL
export GOVC_INSECURE=1
govc find / -type m
y busque el nombre de la imagen en la salida, que enumera los objetos por sus rutas de inventario completas.Para obtener más información sobre las imágenes OVA personalizadas, consulte Compilar imágenes de máquinas.
Puede especificar una región y una zona para el clúster de carga de trabajo, a fin de integrarla con las etiquetas de zona y región configuradas para vSphere CSI (Cloud Storage Interface). Para los clústeres que abarcan varias zonas, esto permite que los nodos de trabajo encuentren y utilicen almacenamiento compartido, incluso si se ejecutan en zonas que no tienen pods de almacenamiento, por ejemplo, en una red de acceso de radio de telecomunicaciones (RAN).
Para implementar un clúster de carga de trabajo con etiquetas de zona y región que habiliten el almacenamiento compartido con vSphere CSI:
Cree etiquetas en vCenter Server:
k8s-region
y k8s-zone
.Siga Crear y editar una etiqueta de vSphere para crear etiquetas dentro de las categorías de región y zona en el centro de datos, como se muestra en esta tabla:
Categoría | Etiquetas |
---|---|
k8s-zone |
zone-a zone-b zone-c |
k8s-region |
region-1 |
Cree las etiquetas correspondientes a los clústeres y en el centro de datos siguiendo Asignar o quitar una etiqueta de vSphere como se indica en la tabla.
Objetos vSphere | Etiquetas |
datacenter |
region-1 |
cluster1 |
zone-a |
cluster2 |
zone-b |
cluster3 |
zone-c |
Para habilitar zonas y regiones personalizadas para un vSphere controlador CSI del clúster de carga de trabajo, establezca las variables VSPHERE_REGION
y VSPHERE_ZONE
en el archivo de configuración del clúster en las etiquetas anteriores. Por ejemplo:
VSPHERE_REGION: region-1
VSPHERE_ZONE: zone-a
Cuando la CLI de Tanzu crea un clúster de carga de trabajo con estas variables configuradas, etiqueta cada nodo del clúster con las claves de topología failure-domain.beta.kubernetes.io/zone
y failure-domain.beta.kubernetes.io/region
.
Ejecute tanzu cluster create
para crear el clúster de carga de trabajo, como se describe en Crear un clúster TKC o basado en un plan.
Después de crear el clúster y con el contexto kubectl
establecido en el clúster, puede comprobar las etiquetas de región y zona mediante una de las siguientes acciones:
Ejecute kubectl get nodes -L failure-domain.beta.kubernetes.io/zone -L failure-domain.beta.kubernetes.io/region
y confirme que el resultado enumera los nodos del clúster.
Ejecute kubectl get csinodes -o jsonpath='{range .items\[\*\]}{.metadata.name} {.spec}{"\\n"}{end}'
y confirme que la región y la zona estén habilitadas en vsphere-csi
.
Para obtener más información sobre cómo configurar vSphere CSI, consulte Controlador vSphere csi: Implementación con topología.
Tanzu Kubernetes Grid puede ejecutar clústeres de carga de trabajo en varias cuentas de la plataforma de destino, por ejemplo, para dividir el uso de la nube entre diferentes equipos o aplicar diferentes perfiles de seguridad a las cargas de trabajo de producción, realización de copias intermedias y desarrollo.
Para implementar clústeres de carga de trabajo en una cuenta de entidad de servicio vSphere alternativa, diferente de la que se utiliza para implementar su clúster de administración, haga lo siguiente:
Establezca el contexto de kubectl
en su clúster de administración:
kubectl config use-context MY-MGMT-CLUSTER@MY-MGMT-CLUSTER
Donde MY-MGMT-CLUSTER
es el nombre del clúster de administración.
Cree un archivo secret.yaml
con el siguiente contenido:
apiVersion: v1
kind: Secret
metadata:
name: SECRET-NAME
namespace: CAPV-MANAGER-NAMESPACE
stringData:
username: VSPHERE-USERNAME
password: VSPHERE-PASSWORD
Donde:
SECRET-NAME
es un nombre que se le otorga al secreto de cliente.CAPV-MANAGER-NAMESPACE
es el espacio de nombres donde se ejecuta el pod capv-manager
. Predeterminado: capv-system
.VSPHERE-USERNAME
y VSPHERE-PASSWORD
son credenciales de inicio de sesión que habilitan el acceso a la cuenta de vSphere alternativa.Utilice el archivo para crear el objeto Secret
:
kubectl apply -f secret.yaml
Cree un archivo identity.yaml
con el siguiente contenido:
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereClusterIdentity
metadata:
name: EXAMPLE-IDENTITY
spec:
secretName: SECRET-NAME
allowedNamespaces:
selector:
matchLabels: {}
Donde:
EXAMPLE-IDENTITY
es el nombre que se utilizará para el objeto. VSphereClusterIdentity
.SECRET-NAME
es el nombre que ha dado al secreto de cliente anteriormente.Utilice el archivo para crear el objeto VsphereClusterIdentity
:
kubectl apply -f identity.yaml
El clúster de administración ahora puede implementar clústeres de carga de trabajo en la cuenta alternativa.
Para implementar un clúster de carga de trabajo en la cuenta:
Cree un manifiesto del clúster ejecutando tanzu cluster create --dry-run
.
Edite la definición VSphereCluster
en el manifiesto para establecer el valor de spec.identityRef.name
para su objeto VSphereClusterIdentity
en el EXAMPLE-IDENTITY
creado anteriormente:
...
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereCluster
metadata:
name: new-workload-cluster
spec:
identityRef:
kind: VSphereClusterIdentity
name: EXAMPLE-IDENTITY
...
Ejecute kubectl apply -f my-cluster-manifest.yaml
para crear el clúster de carga de trabajo.
Después de crear el clúster de carga de trabajo, inicie sesión en vSphere con las credenciales de cuenta alternativas. Debería verlo en ejecución.
Para obtener más información, consulte Administración de identidades en el repositorio de vSphere del proveedor de API del clúster.
NotaEsta función no funciona según lo esperado. Si etiqueta varios almacenes de datos en un clúster de almacenes de datos como base para la directiva de almacenamiento de un clúster de carga de trabajo, el clúster de carga de trabajo utiliza solo uno de los almacenes de datos.
Para permitir que un clúster de carga de trabajo utilice un clúster de almacenes de datos en lugar de un solo almacén de datos, configure una directiva de almacenamiento que tenga como destino todos los almacenes de datos dentro del clúster de almacenes de datos de la siguiente manera:
Cree una etiqueta y asóciela con los almacenes de datos relevantes:
Datastore
como un tipo de objeto asociable.Siga Crear una directiva de almacenamiento de máquina virtual para la colocación basada en etiquetas para crear una directiva de almacenamiento basada en etiquetas.
En el archivo de configuración del clúster:
VSPHERE_STORAGE_POLICY_ID
en el nombre de la directiva de almacenamiento creada en el paso anterior.VSPHERE_DATASTORE
. La configuración de VSPHERE_DATASTORE
anularía la configuración de la directiva de almacenamiento.Para implementar un clúster de carga de trabajo con varios sistemas operativos que tenga nodos de trabajo basados en Linux y Windows, cree una imagen de máquina Windows personalizada, implemente un clúster de carga de trabajo de Windows y, a continuación, agregue una MachineDeployment
de Linux para convertir el clúster de carga de trabajo solo de Windows en un clúster de varios sistemas operativos.
Los clústeres de varios sistemas operativos pueden alojar cargas de trabajo de Linux y Windows mientras se ejecutan componentes de TKG basados en Linux en los nodos de trabajo.
Cree un archivo YAML, por ejemplo,win-osimage.yaml
para agregar una OSImage en el clúster de administración que apunte a la plantilla cuando creó una imagen de máquina de Windows.
Puede utilizar el siguiente archivo YAML de ejemplo. Cambie el valor spec.image.ref.template
a la ubicación de la plantilla de Windows que creó. La ruta de acceso es específica del entorno de vSphere.
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: OSImage
metadata:
name: v1.24.10---vmware.1-tkg.1-windows
spec:
image:
ref:
template: /dc0/vm/windows-2019-kube-v1.24.10+vmware.1-tkg.1
version: v1.24.10+vmware.1-tkg.1-windows
type: ova
kubernetesVersion: v1.24.10+vmware.1
os:
arch: amd64
name: windows
type: windows
version: "2019"
Ejecute kubectl apply -f win-osimage.yaml
para agregar la OSImage.
Agregue la versión de TKR a spec.osImages
para que la resolución de TKR y la validación de webhook se produzcan correctamente. Utilice el siguiente comando para agregar la versión de TKR a spec.osImages
.
$ kubectl edit tkr v1.24.10---vmware.x-tkg.x
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesRelease
metadata:
name: v1.24.10---vmware.x-tkg.x
spec:
bootstrapPackages:
# Keep the other packages listed here.
- name: tkg-windows.tanzu.vmware.com.0.28.1+vmware.1
osImages:
# Keep the other images listed here.
- name: v1.24.10---vmware.1-tkg.1-windows
En TKR, habilite el paquete tkg-windows
agregando un nuevo elemento en spec.bootstrapPackages
. El paquete se puede encontrar en el repositorio oficial con tanzu package available list tkg-windows.tanzu.vmware.com
. A continuación se muestra un ejemplo de un TKR de funcionamiento:
Cree una especificación de objeto de clúster basada en clases ejecutando el siguiente comando:
tanzu cluster create my-cluster --file my-cluster-config.yaml --dry-run > my-cluster-spec.yaml
Donde:
WINDOWS-CLUSTER
es el nombre del clúster de Windows. *
CLUSTER-CONFIG
es el nombre del archivo de configuración.
Añada la nueva clase de implementación de máquina tkg-worker
al objeto del clúster enmy-cluster-spec.yaml
. Asegúrese de que la anotación sea correcta para que TKG pueda buscar el objeto OSImage
.
Puede agregar la nueva especificación tkg-worker
a spec.workers.machineDeployments
similar al siguiente ejemplo:
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: WINDOWS-CLUSTER
spec:
workers:
machineDeployments:
- class: tkg-worker
metadata:
annotations:
run.tanzu.vmware.com/resolve-os-image: image-type=ova,os-name=photon
name: md-0-l
replicas: 1
- class: tkg-worker-windows
metadata:
annotations:
run.tanzu.vmware.com/resolve-os-image: image-type=ova,os-name=windows
name: md-0
replicas: 1
Ejecute el siguiente comando para implementar el clúster de varios sistemas operativos:
tanzu cluster create my-cluster -f my-cluster-spec.yaml
Los nodos se etiquetan y se contaminan con la información del sistema operativo en Etiquetas, anotaciones y contaminaciones conocidas.
NotaNo se admite la copia de seguridad ni la restauración de clústeres de carga de trabajo de varios sistemas operativos.
La red de HNS no es persistente en Windows. Después de reiniciar el nodo de Windows, se elimina la red HNS creada por antrea-agent y la extensión Open vSwitch se deshabilita de forma predeterminada. Por lo tanto, una vez que se reinicie el nodo de Windows, elimine los puertos y el puente de OVS obsoletos. Puede utilizar el script de ayuda Clean-AntreaNetwork.ps1
para limpiar el puente OVS.
Utilice uno de los siguientes métodos para instalar el script de ayuda:
Para instalar manualmente el script de ayuda en cada nodo de carga de trabajo aislado:
Clean-AntreaNetwork.ps1
desde este ejemplo de código. El script de instalación descargado snippet.ps1
instala Clean-AntreaNetwork.ps1
.Acceda mediante SSH al nodo de y ejecute el siguiente comando.
powershell snippet.ps1
Para crear un ClusterClass
que instale automáticamente el script de ayuda en cada nodo de carga de trabajo nuevo:
Aplique la revisión de este ejemplo de código mediante YTT y aplique la especificación en el clúster de administración:
ytt -f custom-cluster-class.yaml -f snippet.yaml | kubectl apply -f -
Si implementa clústeres de Windows o MultiOS, debe asegurarse de que los grupos de puertos distribuidos tengan ciertas directivas de seguridad establecidas en Reject
. Por ejemplo, si el modo promiscuo está establecido en Accept
, los nodos pueden alternar entre los estados Ready
y NotReady
.
En el vSphere Client, seleccione la red que utiliza para los nodos de Windows, vaya a Conmutador virtual distribuido (virtual Distributed Switch) > Directiva de seguridad de grupo de puertos distribuido (Distributed Portgroup Security Policy) y establezca estas directivas en Reject
: