|
Este documento ha sido traducido utilizando tecnología de traducción automática. Si bien nos esforzamos por proporcionar traducciones precisas, no ofrecemos garantías sobre la integridad, precisión o confiabilidad del contenido traducido. En caso de discrepancia, la versión original en inglés prevalecerá y constituirá el texto autorizado. |
Configurando el proveedor de nube de Azure
|
Importante:
En Kubernetes 1.30 y versiones posteriores, debes usar un proveedor de nube de Azure externo. El proveedor de nube de Azure ha sido eliminado completamente, y no funcionará después de actualizar a Kubernetes 1.30. Los pasos que se enumeran a continuación siguen siendo necesarios para configurar un proveedor de nube de Azure. Puedes configurar un proveedor de nube externo tras completar los requisitos previos para Azure. También puedes migrar de un proveedor de nube interno a un proveedor de nube externo de Azure en Kubernetes 1.29 y versiones anteriores. Todos los clústeres existentes deben migrar antes de actualizar a v1.30 para seguir siendo funcionales. A partir de Kubernetes 1.29, los proveedores de nube internos se han deshabilitado. Debes establecer A partir de la versión 1.26 de Kubernetes, los tipos de volumen persistente internos |
Al usar el proveedor de nube Azure, puedes aprovechar las siguientes capacidades:
-
Balanceadores de Carga: Lanza un equilibrador de carga de Azure dentro de un grupo de seguridad de red específico.
-
Volúmenes persistentes: Soporta el uso de discos de Blob de Azure y discos administrados de Azure con cuentas de almacenamiento estándar y premium.
-
Almacenamiento de red: Soporta Azure Files a través de montajes CIFS.
Los siguientes tipos de cuentas no son compatibles con las suscripciones de Azure:
-
Cuentas de un solo inquilino (es decir, cuentas sin suscripciones).
-
Cuentas con varias suscripciones.
Requisitos previos para RKE y SUSE® Rancher Prime: RKE2
Para configurar el proveedor de nube de Azure para RKE y RKE2, es necesario configurar las siguientes credenciales:
1. Configurar el ID de inquilino de Azure
Visita el portal de Azure, inicia sesión y ve a Azure Active Directory y selecciona Propiedades. Tu ID de directorio es tu ID de inquilino (tenantID).
Si deseas usar la CLI de Azure, puedes ejecutar el comando az account show para obtener la información.
2. Configurar el ID de cliente de Azure y el secreto de cliente de Azure
Visita el portal de Azure, inicia sesión y sigue los pasos a continuación para crear una inscripción de aplicación y el correspondiente ID de cliente de Azure (aadClientId) y secreto de cliente de Azure (aadClientSecret).
-
Seleccione Azure Active Directory.
-
Seleccione Registros de aplicaciones.
-
Seleccione Nueva inscripción de aplicación.
-
Elija un Nombre, seleccione
Web app / APIcomo Tipo de aplicación y un URL de inicio de sesión que puede ser cualquier cosa en este caso. -
Selecciona Crear.
En la vista de Registros de aplicaciones, deberías ver tu inscripción de aplicación creada. El valor mostrado en la columna IDENTIFICADOR DE APLICACIÓN es el que debes usar como ID de cliente de Azure.
El siguiente paso es generar el Secreto de cliente de Azure:
-
Abre tu inscripción de aplicación creada.
-
En la vista de Ajustes, abre Claves.
-
Introduce una Descripción de clave, selecciona un tiempo de expiración y pulsa Guardar.
-
El valor generado mostrado en la columna Valor es el que debes usar como Secreto de cliente de Azure. Este valor solo se mostrará una vez.
3. Configurar permisos de inscripción de aplicación
Lo último que necesitas hacer es asignar los permisos apropiados a tu inscripción de aplicación.
-
Ve a Más servicios, busca Suscripciones y ábrelo.
-
Abre Control de acceso (IAM).
-
Selecciona Añadir.
-
Para Rol, selecciona
Contributor. -
Para Seleccionar, selecciona el nombre de tu inscripción de aplicación creada.
-
Selecciona Guardar.
4. Configura el nombre del grupo de seguridad de red de Azure.
Se necesita un Grupo de Seguridad de Red de Azure personalizado (securityGroupName) para permitir que los Balanceadores de Carga de Azure funcionen.
Si aprovisionas hosts utilizando el controlador de Azure de Rancher Machine, deberás editarlos manualmente para asignarlos a este Grupo de Seguridad de Red.
Ya deberías haber asignado hosts personalizados a este Grupo de Seguridad de Red durante el aprovisionamiento.
Solo los hosts que se espera que sean los sistemas secundarios del balanceador de carga necesitan estar en este grupo.
SUSE® Rancher Prime: RKE2 Configuración del Clúster en Rancher
|
Importante:
Esta sección es válida solo para crear clústeres con el proveedor de nube interno. |
-
Elige "Azure" del menú desplegable del Proveedor de Nube en la sección de Configuración del Clúster.
-
Proporciona la Configuración del Proveedor de Nube. Ten en cuenta que Rancher crea automáticamente un nuevo Grupo de Seguridad de Red, Grupo de Recursos, Conjunto de Disponibilidad, Subred y Red Virtual. Si ya tienes algunos o todos estos creados, debes especificarlos antes de crear el clúster.
-
Haz clic en Mostrar Avanzado para ver o editar estos nombres generados automáticamente. Tu Configuración del Proveedor de Nube debe coincidir con los campos en la sección Grupos de Máquinas. Si tienes múltiples grupos, todos deben usar el mismo Grupo de Recursos, Conjunto de Disponibilidad, Subred, Red Virtual y Grupo de Seguridad de Red.
-
A continuación se proporciona un ejemplo. Modifícalo según sea necesario.
Ejemplo de Configuración del Proveedor de Nube
+
{ "cloud":"AzurePublicCloud", "tenantId": "YOUR TENANTID HERE", "aadClientId": "YOUR AADCLIENTID HERE", "aadClientSecret": "YOUR AADCLIENTSECRET HERE", "subscriptionId": "YOUR SUBSCRIPTIONID HERE", "resourceGroup": "docker-machine", "location": "westus", "subnetName": "docker-machine", "securityGroupName": "rancher-managed-KA4jV9V2", "securityGroupResourceGroup": "docker-machine", "vnetName": "docker-machine-vnet", "vnetResourceGroup": "docker-machine", "primaryAvailabilitySetName": "docker-machine", "routeTableResourceGroup": "docker-machine", "cloudProviderBackoff": false, "useManagedIdentityExtension": false, "useInstanceMetadata": true }+
-
-
En la sección menu:Configuración del Clúster[Avanzado], haz clic en Añadir bajo Argumentos Adicionales del Gestor de Controladores y añade esta bandera:
--configure-cloud-routes=false -
Haz clic en Crear para enviar el formulario y crear el clúster.
Configuración del Proveedor de Nube
Rancher crea automáticamente un nuevo Grupo de Seguridad de Red, Grupo de Recursos, Conjunto de Disponibilidad, Subred y Red Virtual. Si ya tienes algunos o todos estos creados, necesitarás especificarlos antes de crear el clúster. Puedes consultar Plantillas de Nodo RKE1 o Grupos de Máquinas RKE2 para ver o editar estos nombres generados automáticamente.
Consulta la lista completa de opciones de configuración en la documentación upstream.
|
Azure admite la lectura de la configuración de la nube desde secretos de Kubernetes. El secreto es una versión serializada del archivo azure.json. Cuando se cambia el secreto, el administrador del controlador de la nube se reconstruye sin reiniciar el pod. Se recomienda que el gráfico de Helm lea la Configuración del Proveedor de Nube desde el secreto.
Ten en cuenta que el chart lee la configuración del proveedor de nube desde un nombre de secreto dado en el espacio de nombres kube-system. Dado que Azure lee secretos de Kubernetes, también es necesario configurar RBAC. A continuación se muestra un ejemplo de secreto para la configuración del proveedor de nube. Modifícalo según sea necesario y crea el secreto.
# azure-cloud-config.yaml
apiVersion: v1
kind: Secret
metadata:
name: azure-cloud-config
namespace: kube-system
type: Opaque
stringData:
cloud-config: |-
{
"cloud": "AzurePublicCloud",
"tenantId": "<tenant-id>",
"subscriptionId": "<subscription-id>",
"aadClientId": "<client-id>",
"aadClientSecret": "<client-secret>",
"resourceGroup": "docker-machine",
"location": "westus",
"subnetName": "docker-machine",
"securityGroupName": "rancher-managed-kqmtsjgJ",
"securityGroupResourceGroup": "docker-machine",
"vnetName": "docker-machine-vnet",
"vnetResourceGroup": "docker-machine",
"primaryAvailabilitySetName": "docker-machine",
"routeTableResourceGroup": "docker-machine",
"cloudProviderBackoff": false,
"useManagedIdentityExtension": false,
"useInstanceMetadata": true,
"loadBalancerSku": "standard",
"excludeMasterFromStandardLB": false,
}
Usando el Proveedor de Nube de Azure fuera del árbol.
-
RKE2
-
RKE1
-
Selecciona Externo del menú desplegable Proveedor de Nube en la sección Configuración del Clúster.
-
Bajo menu:Configuración del Clúster[Avanzado], haz clic en Añadir bajo Argumentos Adicionales del Administrador de Controladores y añade esta bandera:
--configure-cloud-routes=false. -
Prepara la configuración del proveedor de nube para establecerla en el siguiente paso. Ten en cuenta que Rancher crea automáticamente un nuevo Grupo de Seguridad de Red, Grupo de Recursos, Conjunto de Disponibilidad, Subred y Red Virtual. Si ya tienes algunos o todos estos creados, debes especificarlos antes de crear el clúster.
Haz clic en Mostrar Avanzado para ver o editar estos nombres generados automáticamente. Tu configuración del proveedor de nube debe coincidir con los campos en la sección Grupos de Máquinas. Si tienes múltiples grupos de máquinas, todos deben usar el mismo Grupo de Recursos, Conjunto de Disponibilidad, Subred, Red Virtual y Grupo de Seguridad de Red.
-
Bajo Configuración del Clúster > Configuración de Complementos, añade el manifiesto del gestor de controladores de nube que se muestra a continuación en Manifiesto Adicional.
Ten en cuenta que este chart lee la Configuración del Proveedor de Nube del secreto en el espacio de nombres
kube-system. Un ejemplo de secreto para la configuración del proveedor de nube se muestra a continuación; modifícalo según sea necesario. Consulta la lista completa de opciones de configuración en la documentación de sentido ascendente.Alternativamente, también puedes instalar el gestor de controladores de nube utilizando el CLI de Helm.
apiVersion: helm.cattle.io/v1 kind: HelmChart metadata: name: azure-cloud-controller-manager namespace: kube-system spec: chart: cloud-provider-azure repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo targetNamespace: kube-system bootstrap: true valuesContent: |- infra: clusterName: <cluster-name> cloudControllerManager: cloudConfigSecretName: azure-cloud-config cloudConfig: null clusterCIDR: null enableDynamicReloading: 'true' nodeSelector: node-role.kubernetes.io/control-plane: 'true' allocateNodeCidrs: 'false' hostNetworking: true caCertDir: /etc/ssl configureCloudRoutes: 'false' enabled: true tolerations: - effect: NoSchedule key: node-role.kubernetes.io/master - effect: NoSchedule key: node-role.kubernetes.io/control-plane value: 'true' - effect: NoSchedule key: node.cloudprovider.kubernetes.io/uninitialized value: 'true' --- apiVersion: v1 kind: Secret metadata: name: azure-cloud-config namespace: kube-system type: Opaque stringData: cloud-config: |- { "cloud": "AzurePublicCloud", "tenantId": "<tenant-id>", "subscriptionId": "<subscription-id>", "aadClientId": "<client-id>", "aadClientSecret": "<client-secret>", "resourceGroup": "docker-machine", "location": "westus", "subnetName": "docker-machine", "securityGroupName": "rancher-managed-kqmtsjgJ", "securityGroupResourceGroup": "docker-machine", "vnetName": "docker-machine-vnet", "vnetResourceGroup": "docker-machine", "primaryAvailabilitySetName": "docker-machine", "routeTableResourceGroup": "docker-machine", "cloudProviderBackoff": false, "useManagedIdentityExtension": false, "useInstanceMetadata": true, "loadBalancerSku": "standard", "excludeMasterFromStandardLB": false, } -
Haz clic en Crear para enviar el formulario y crear el clúster.
-
Elige Externo del menú desplegable Proveedor de Nube en la sección Opciones del Clúster. Esto establece
--cloud-provider=externalpara los componentes de Kubernetes. -
Instala el chart
cloud-provider-azuredespués de que el clúster termine de aprovisionarse. Ten en cuenta que el clúster no se ha aprovisionado con éxito y los nodos siguen en un estadouninitializedhasta que despliegues el gestor de controladores de nube. Esto se puede hacer manualmente usando CLI, o a través de charts de Helm en la interfaz de usuario.
Consulta la documentación oficial de Azure de sentido ascendente para más detalles sobre el despliegue del Gestor de Controladores de Nube.
Instalación del Chart de Helm desde CLI
La documentación oficial de sentido ascendente para la instalación del chart de Helm se puede encontrar en Github.
-
Crea un secreto de
azure-cloud-configcon la configuración del proveedor de nube requerida.kubectl apply -f azure-cloud-config.yaml -
Añade el repositorio de Helm:
helm repo add azure-cloud-controller-manager https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo helm repo update -
Crea un archivo
values.yamlcon el siguiente contenido para sobrescribir elvalues.yamlpor defecto:-
RKE2
-
RKE
# values.yaml infra: clusterName: <cluster-name> cloudControllerManager: cloudConfigSecretName: azure-cloud-config cloudConfig: null clusterCIDR: null enableDynamicReloading: 'true' configureCloudRoutes: 'false' allocateNodeCidrs: 'false' caCertDir: /etc/ssl enabled: true replicas: 1 hostNetworking: true nodeSelector: node-role.kubernetes.io/control-plane: 'true' tolerations: - effect: NoSchedule key: node-role.kubernetes.io/master - effect: NoSchedule key: node-role.kubernetes.io/control-plane value: 'true' - effect: NoSchedule key: node.cloudprovider.kubernetes.io/uninitialized value: 'true'# values.yaml cloudControllerManager: cloudConfigSecretName: azure-cloud-config cloudConfig: null clusterCIDR: null enableDynamicReloading: 'true' configureCloudRoutes: 'false' allocateNodeCidrs: 'false' caCertDir: /etc/ssl enabled: true replicas: 1 hostNetworking: true nodeSelector: node-role.kubernetes.io/controlplane: 'true' node-role.kubernetes.io/control-plane: null tolerations: - effect: NoSchedule key: node-role.kubernetes.io/controlplane value: 'true' - effect: NoSchedule key: node.cloudprovider.kubernetes.io/uninitialized value: 'true' infra: clusterName: <cluster-name> -
-
Instala el chart de Helm:
helm upgrade --install cloud-provider-azure azure-cloud-controller-manager/cloud-provider-azure -n kube-system --values values.yamlVerifica que el chart de Helm se haya instalado correctamente:
helm status cloud-provider-azure -n kube-system -
(Opcional) Verifica que la actualización del gestor de controladores de nube haya tenido éxito:
kubectl rollout status deployment -n kube-system cloud-controller-manager kubectl rollout status daemonset -n kube-system cloud-node-manager -
El proveedor de la nube es responsable de establecer el ProviderID del nodo. Verifica si todos los nodos están inicializados con el ProviderID:
kubectl describe nodes | grep "ProviderID"
Instalación del Helm Chart desde la interfaz de usuario
-
Haz clic en ☰, luego selecciona el nombre del clúster en la navegación izquierda.
-
Selecciona Aplicaciones > Repositorios.
-
Haz clic en el botón Crear.
-
Introduce
https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repoen el campo URL del índice. -
Selecciona Aplicaciones > Charts en la navegación izquierda e instala el chart cloud-provider-azure.
-
Selecciona el espacio de nombres,
kube-system, y habilita Personalizar opciones de Helm antes de la instalación. -
Reemplaza
cloudConfig: /etc/kubernetes/azure.jsonpara leer desde el Cloud Config Secret y habilita la recarga dinámica:cloudConfigSecretName: azure-cloud-config enableDynamicReloading: 'true' -
Actualiza los siguientes campos según sea necesario:
allocateNodeCidrs: 'false' configureCloudRoutes: 'false' clusterCIDR: null
-
RKE2
-
RKE
-
Los nodos RKE2 provisionados por Rancher tienen el selector
node-role.kubernetes.io/control-planeestablecido entrue. Actualiza el nodeSelector:nodeSelector: node-role.kubernetes.io/control-plane: 'true'
-
Los nodos RKE provisionados por Rancher tienen un taint
node-role.kubernetes.io/controlplane. Actualiza las tolerancias y el nodeSelector:tolerations: - effect: NoSchedule key: node.cloudprovider.kubernetes.io/uninitialized value: 'true' - effect: NoSchedule value: 'true' key: node-role.kubernetes.io/controlplanenodeSelector: node-role.kubernetes.io/controlplane: 'true'
-
Instala el chart y confirma que el controlador de nube y el administrador de nodos de nube se desplegaron correctamente:
kubectl rollout status deployment -n kube-system cloud-controller-manager kubectl rollout status daemonset -n kube-system cloud-node-manager -
El proveedor de la nube es responsable de establecer el ProviderID del nodo. Verifica si todos los nodos están inicializados con el ProviderID:
kubectl describe nodes | grep "ProviderID"
Instalando controladores CSI
Instala controlador CSI de Azure Disk o controlador CSI de Azure File para acceder a Azure Disk o Azure File volúmenes respectivamente.
Los pasos para instalar el controlador CSI de Azure Disk se muestran a continuación. Puedes instalar el controlador CSI de Azure File de manera similar siguiendo la documentación de instalación de Helm.
|
Importante
Los clústeres deben ser aprovisionados utilizando |
La documentación oficial de sentido ascendente para la instalación del chart de Helm se puede encontrar en Github.
-
Añade y actualiza el repositorio de Helm:
helm repo add azuredisk-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/charts helm repo update azuredisk-csi-driver -
Instala el chart como se muestra a continuación, actualizando el argumento de versión de — según sea necesario. Consulta la lista completa de las últimas configuraciones del chart en la documentación de sentido ascendente.
helm install azuredisk-csi-driver azuredisk-csi-driver/azuredisk-csi-driver --namespace kube-system --version v1.30.1 --set controller.cloudConfigSecretName=azure-cloud-config --set controller.cloudConfigSecretNamespace=kube-system --set controller.runOnControlPlane=true -
(Opcional) Verifica que la instalación del controlador azuredisk-csi-driver haya sido exitosa:
kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/name=azuredisk-csi-driver" --watch -
Aprovisiona una clase de almacenamiento de ejemplo:
cat <<EOF | kubectl create -f - kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: standard provisioner: kubernetes.io/azure-disk parameters: storageaccounttype: Standard_LRS kind: Managed EOFVerifica que la clase de almacenamiento haya sido aprovisionada:
kubectl get storageclasses -
Crea un PersistentVolumeClaim:
cat <<EOF | kubectl create -f - kind: PersistentVolumeClaim apiVersion: v1 metadata: name: azure-disk-pvc spec: storageClassName: standard accessModes: ** ReadWriteOnce resources: requests: storage: 5Gi EOFVerifica que el PersistentVolumeClaim y el PersistentVolume han sido creados:
kubectl get persistentvolumeclaim kubectl get persistentvolume -
Adjunta el nuevo Azure Disk:
Ahora puedes montar el PersistentVolume de Kubernetes en un Pod de Kubernetes. El disco puede ser consumido por cualquier tipo de objeto de Kubernetes, incluyendo un Deployment, DaemonSet o StatefulSet. Sin embargo, el siguiente ejemplo simplemente monta el PersistentVolume en un Pod independiente.
cat <<EOF | kubectl create -f - kind: Pod apiVersion: v1 metadata: name: mypod-dynamic-azuredisk spec: containers: - name: mypod image: nginx ports: - containerPort: 80 name: "http-server" volumeMounts: - mountPath: "/usr/share/nginx/html" name: storage volumes: - name: storage persistentVolumeClaim: claimName: azure-disk-pvc EOF