|
Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official. |
Configuração do Provedor de Nuvem Azure
|
Importante:
No Kubernetes 1.30 e versões posteriores, você deve usar um provedor de nuvem Azure fora da árvore. O provedor de nuvem Azure foi removido completamente e não funcionará após uma atualização para o Kubernetes 1.30. Os passos listados abaixo ainda são necessários para a configuração de um provedor de nuvem Azure. Você pode configurar um provedor de nuvem fora da árvore após concluir os pré-requisitos para o Azure. Você também pode migrar de um provedor de nuvem dentro da árvore para um provedor de nuvem fora da árvore Azure no Kubernetes 1.29 e versões anteriores. Todos os clusters existentes devem migrar antes de atualizar para a v1.30 para continuar funcionais. A partir do Kubernetes 1.29, provedores de nuvem dentro da árvore foram desativados. Você deve definir A partir da versão 1.26 do Kubernetes, os tipos de volume persistente dentro da árvore |
Ao usar o provedor de nuvem Azure, você pode aproveitar as seguintes capacidades:
-
Balanceadores de Carga: Lança um Balanceador de Carga Azure dentro de um Grupo de Segurança de Rede específico.
-
Volumes Persistentes: Suporta o uso de discos Azure Blob e Discos Gerenciados do Azure com contas de armazenamento padrão e premium.
-
Armazenamento em rede: Suporta Azure Files via montagens CIFS.
Os seguintes tipos de conta não são suportados para Assinaturas do Azure:
-
Contas de único inquilino (ou seja, contas sem assinaturas).
-
Contas de múltiplas assinaturas.
Pré-requisitos para RKE e SUSE® Rancher Prime: RKE2
Para configurar o provedor de nuvem Azure para RKE e RKE2, as seguintes credenciais precisam ser configuradas:
1. Configurar o ID do Inquilino do Azure
Visite portal do Azure, faça login e vá para Azure Active Directory e selecione Propriedades. Seu ID do Diretório é seu ID do Inquilino (tenantID).
Se você quiser usar a CLI do Azure, pode executar o comando az account show para obter as informações.
2. Configurar o ID do Cliente do Azure e o Segredo do Cliente do Azure
Visite portal do Azure, faça login e siga os passos abaixo para criar um Registro de Aplicativo e o correspondente ID do Cliente do Azure (aadClientId) e Segredo do Cliente do Azure (aadClientSecret).
-
Selecione Azure Active Directory.
-
Selecione Registros de aplicativos.
-
Selecione Novo registro de aplicativo.
-
Escolha um Nome, selecione
Web app / APIcomo Tipo de Aplicativo e um URL de Acesso que pode ser qualquer coisa neste caso. -
Selecione Criar.
Na visualização Registros de aplicativos, você deve ver seu Registro de aplicativo criado. O valor mostrado na coluna ID DA APLICAÇÃO é o que você precisa usar como ID do Cliente do Azure.
O próximo passo é gerar o Segredo do Cliente do Azure:
-
Abra seu Registro de aplicativo criado.
-
Na visualização Configurações, abra Chaves.
-
Digite uma Descrição da chave, selecione um tempo de expiração e selecione Salvar.
-
O valor gerado mostrado na coluna Valor é o que você precisa usar como Segredo do Cliente do Azure. Esse valor será mostrado apenas uma vez.
3. Configurar Permissões de Registro de Aplicativo
A última coisa que você precisará fazer é atribuir as permissões apropriadas ao seu Registro de aplicativo.
-
Vá para Mais serviços, pesquise por Assinaturas e abra-o.
-
Abra Controle de Acesso (IAM).
-
Selecione Adicionar.
-
Para Papel, selecione
Contributor. -
Para Selecionar, selecione o nome do seu Registro de aplicativo criado.
-
Selecione Salvar.
4. Configurar o Nome do Grupo de Segurança de Rede do Azure
Um Grupo de Segurança de Rede do Azure personalizado (securityGroupName) é necessário para permitir que os Balanceadores de Carga do Azure funcionem.
Se você provisionar hosts usando o driver Azure do Rancher Machine, precisará editá-los manualmente para atribuí-los a este Grupo de Segurança de Rede.
Você já deve atribuir hosts personalizados a este Grupo de Segurança de Rede durante a provisão.
Apenas os hosts que devem ser back end do balanceador de carga precisam estar neste grupo.
SUSE® Rancher Prime: RKE2 Configuração do Cluster no Rancher
|
Importante:
Esta seção é válida apenas para a criação de clusters com o provedor de nuvem dentro da árvore. |
-
Escolha "Azure" no menu suspenso do Provedor de Nuvem na seção de Configuração do Cluster.
-
Forneça a Configuração do Provedor de Nuvem. Observe que o Rancher cria automaticamente um novo Grupo de Segurança de Rede, Grupo de Recursos, Conjunto de Disponibilidade, Sub-rede e Rede Virtual. Se você já tiver alguns ou todos esses criados, deve especificá-los antes de criar o cluster.
-
Clique em Mostrar Avançado para visualizar ou editar esses nomes gerados automaticamente. Sua Configuração do Provedor de Nuvem deve corresponder aos campos na seção Pools de Máquinas. Se você tiver vários pools, todos devem usar o mesmo Grupo de Recursos, Conjunto de Disponibilidade, Sub-rede, Rede Virtual e Grupo de Segurança de Rede.
-
Um exemplo é fornecido abaixo. Modifique conforme necessário.
Exemplo de Configuração do Provedor de Nuvem
+
{ "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 }+
-
-
Na seção menu:Configuração do Cluster[Avançado], clique em Adicionar em Argumentos Adicionais do Gerenciador de Controlador e adicione esta flag:
--configure-cloud-routes=false -
Clique em Criar para enviar o formulário e criar o cluster.
Configuração do Provedor de Nuvem
O Rancher cria automaticamente um novo Grupo de Segurança de Rede, Grupo de Recursos, Conjunto de Disponibilidade, Sub-rede e Rede Virtual. Se você já tiver alguns ou todos esses criados, precisará especificá-los antes de criar o cluster. Você pode verificar Modelos de Nó RKE1 ou Pools de Máquinas RKE2 para visualizar ou editar esses nomes gerados automaticamente.
Consulte a lista completa de opções de configuração na documentação upstream.
|
O Azure suporta a leitura da configuração da nuvem a partir de segredos do Kubernetes. O segredo é uma versão serializada do arquivo azure.json. Quando o segredo é alterado, o gerenciador de controladores de nuvem se reconstrói sem reiniciar o pod. É recomendado que o gráfico Helm leia a Configuração do Provedor de Nuvem a partir do segredo.
Observe que o gráfico lê a Configuração do Provedor de Nuvem a partir de um nome de segredo específico no namespace kube-system. Como o Azure lê segredos do Kubernetes, o RBAC também precisa ser configurado. Um exemplo de segredo para a Configuração do Provedor de Nuvem é mostrado abaixo. Modifique conforme necessário e crie o segredo.
# 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 o Provedor de Nuvem Azure fora da árvore.
-
RKE2
-
RKE1
-
Selecione Externo no menu suspenso Provedor de Nuvem na seção Configuração do Cluster.
-
Em menu:Configuração do Cluster[Avançado], clique em Adicionar em Argumentos Adicionais do Gerenciador de Controladores e adicione esta flag:
--configure-cloud-routes=false. -
Prepare a Configuração do Provedor de Nuvem para defini-la na próxima etapa. Observe que o Rancher cria automaticamente um novo Grupo de Segurança de Rede, Grupo de Recursos, Conjunto de Disponibilidade, Sub-rede e Rede Virtual. Se você já tiver alguns ou todos esses criados, deve especificá-los antes de criar o cluster.
Clique em Mostrar Avançado para visualizar ou editar esses nomes gerados automaticamente. Sua Configuração do Provedor de Nuvem deve corresponder aos campos na seção Pools de Máquinas. Se você tiver vários pools, todos devem usar o mesmo Grupo de Recursos, Conjunto de Disponibilidade, Sub-rede, Rede Virtual e Grupo de Segurança de Rede.
-
Em Configuração do Cluster > Configuração de Complemento, adicione o manifesto do gerenciador de controladores de nuvem mostrado abaixo em Manifesto Adicional.
Observe que este gráfico lê a Configuração do Provedor de Nuvem a partir do segredo no namespace
kube-system. Um exemplo de segredo para a Configuração do Provedor de Nuvem é mostrado abaixo; modifique conforme necessário. Consulte a lista completa de opções de configuração na documentação upstream.Alternativamente, você também pode instalar o gerenciador de controladores de nuvem usando o Helm CLI.
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, } -
Clique em Criar para enviar o formulário e criar o cluster.
-
Escolha Externo no menu suspenso Provedor de Nuvem na seção Opções do Cluster. Isso define
--cloud-provider=externalpara os componentes do Kubernetes. -
Instale o gráfico
cloud-provider-azureapós o cluster terminar o provisionamento. Observe que o cluster não está provisionado com sucesso e os nós ainda estão em um estadouninitializedaté que você implante o gerenciador de controladores de nuvem. Isso pode ser feito manualmente usando CLI, ou via gráficos do Helm na UI.
Consulte a documentação oficial upstream do Azure para mais detalhes sobre a implantação do Gerenciador de Controladores de Nuvem.
Instalação do Helm Chart a partir da CLI
A documentação oficial upstream para instalação do chart do Helm pode ser encontrada no Github.
-
Crie um segredo
azure-cloud-configcom a configuração do provedor de nuvem necessária.kubectl apply -f azure-cloud-config.yaml -
Adicione o repositório Helm:
helm repo add azure-cloud-controller-manager https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo helm repo update -
Crie um arquivo
values.yamlcom o seguinte conteúdo para substituir ovalues.yamlpadrão:-
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> -
-
Instale o chart do Helm:
helm upgrade --install cloud-provider-azure azure-cloud-controller-manager/cloud-provider-azure -n kube-system --values values.yamlVerifique se o chart do Helm foi instalado com sucesso:
helm status cloud-provider-azure -n kube-system -
(Opcional) Verifique se a atualização do gerenciador de controladores de nuvem foi bem-sucedida:
kubectl rollout status deployment -n kube-system cloud-controller-manager kubectl rollout status daemonset -n kube-system cloud-node-manager -
O provedor de nuvem é responsável por definir o ProviderID do nó. Verifique se todos os nós estão inicializados com o ProviderID:
kubectl describe nodes | grep "ProviderID"
Instalação do Helm Chart a partir da UI
-
Clique ☰, depois selecione o nome do cluster na navegação à esquerda.
-
Selecione Apps > Repositórios.
-
Clique no botão Criar.
-
Digite
https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repono campo URL do Índice. -
Selecione Apps > Charts na navegação à esquerda e instale o chart cloud-provider-azure.
-
Selecione o namespace,
kube-system, e habilite Personalizar opções do Helm antes da instalação. -
Substitua
cloudConfig: /etc/kubernetes/azure.jsonpara ler do Cloud Config Secret e habilite o recarregamento dinâmico:cloudConfigSecretName: azure-cloud-config enableDynamicReloading: 'true' -
Atualize os seguintes campos conforme necessário:
allocateNodeCidrs: 'false' configureCloudRoutes: 'false' clusterCIDR: null
-
RKE2
-
RKE
-
Os nós RKE2 provisionados pelo Rancher têm o seletor
node-role.kubernetes.io/control-planedefinido comotrue. Atualize o nodeSelector:nodeSelector: node-role.kubernetes.io/control-plane: 'true'
-
Os nós RKE provisionados pelo Rancher estão com taints aplicados
node-role.kubernetes.io/controlplane. Atualize as tolerâncias e o 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'
-
Instale o chart e confirme que o controlador de nuvem e o gerenciador de nós da nuvem foram implantados com sucesso:
kubectl rollout status deployment -n kube-system cloud-controller-manager kubectl rollout status daemonset -n kube-system cloud-node-manager -
O provedor de nuvem é responsável por definir o ProviderID do nó. Verifique se todos os nós estão inicializados com o ProviderID:
kubectl describe nodes | grep "ProviderID"
Instalando Drivers CSI
Instale driver CSI de Disco do Azure ou driver CSI de Arquivo do Azure para acessar Disco do Azure ou Arquivo do Azure volumes respectivamente.
Os passos para instalar o driver CSI de Disco do Azure estão mostrados abaixo. Você pode instalar o driver CSI de Arquivo do Azure de maneira semelhante seguindo a documentação de instalação do Helm.
|
Importante
Os clusters devem ser provisionados usando |
A documentação oficial upstream para instalação do chart do Helm pode ser encontrada no Github.
-
Adicione e atualize o repositório Helm:
helm repo add azuredisk-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/charts helm repo update azuredisk-csi-driver -
Instale o chart conforme mostrado abaixo, atualizando o argumento de versão de — conforme necessário. Consulte a lista completa das configurações mais recentes do chart do Helm na documentação upstream.
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) Verifique se a instalação do azuredisk-csi-driver foi bem-sucedida:
kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/name=azuredisk-csi-driver" --watch -
Provisione uma Classe de Armazenamento de exemplo:
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 EOFVerifique se a classe de armazenamento foi provisionada:
kubectl get storageclasses -
Crie um PersistentVolumeClaim:
cat <<EOF | kubectl create -f - kind: PersistentVolumeClaim apiVersion: v1 metadata: name: azure-disk-pvc spec: storageClassName: standard accessModes: ** ReadWriteOnce resources: requests: storage: 5Gi EOFVerifique se o PersistentVolumeClaim e o PersistentVolume foram criados:
kubectl get persistentvolumeclaim kubectl get persistentvolume -
Anexe o novo Disco do Azure:
Agora você pode montar o PersistentVolume do Kubernetes em um Pod do Kubernetes. O disco pode ser consumido por qualquer tipo de objeto do Kubernetes, incluindo uma implantação, um daemonset ou um statefulset. No entanto, o seguinte exemplo simplesmente monta o PersistentVolume em um Pod autônomo.
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