Partilhar via

Perguntas Frequentes – Kubernetes e GitOps compatíveis com o Azure Arc

  • Artigo

Este artigo aborda perguntas frequentes sobre o Kubernetes e o GitOps habilitados para Azure Arc.

Qual é a diferença entre o Kubernetes habilitado para Azure Arc e o Serviço Kubernetes do Azure (AKS)?

AKS é a oferta Kubernetes gerenciada pelo Azure. O AKS simplifica a implantação de um cluster Kubernetes gerenciado no Azure transferindo grande parte da complexidade e da sobrecarga operacional para o Azure. Como os mestres do Kubernetes são gerenciados pelo Azure, você gerencia e mantém apenas os nós do agente.

O Kubernetes habilitado para ArcGIS do Azure permite que você estenda os recursos de gerenciamento do Azure (como o Azure Monitor e a Política do Azure) conectando clusters do Kubernetes ao Azure. Você mantém o próprio cluster Kubernetes subjacente.

Preciso conectar meus clusters AKS em execução no Azure ao Azure Arc?

Atualmente, conectar um cluster do Serviço Kubernetes do Azure (AKS) ao Azure Arc não é necessário para a maioria dos cenários. Talvez você queira conectar um cluster para executar determinados serviços habilitados para Azure Arc, como Serviços de Aplicativo e Serviços de Dados sobre o cluster. Isso pode ser feito usando o recurso de locais personalizados do Kubernetes habilitado para Arco do Azure.

Devo conectar meu cluster AKS-HCI e clusters Kubernetes no Azure Stack Edge ao Azure Arc?

Conectar seu cluster AKS-HCI ou clusters Kubernetes no Azure Stack Edge ao Azure Arc fornece clusters com representação de recursos no Azure Resource Manager. Essa representação de recursos estende recursos como Configuração de Cluster, Azure Monitor e Política do Azure (Gatekeeper) para clusters Kubernetes conectados.

Se o cluster Kubernetes habilitado para Azure Arc estiver no Azure Stack Edge, AKS no Azure Stack HCI (>= atualização de abril de 2021) ou AKS no Windows Server 2019 Datacenter (>= atualização de abril de 2021), a configuração do Kubernetes será incluída gratuitamente.

Como faço para lidar com recursos expirados do Kubernetes habilitados para Azure Arc?

A identidade gerenciada atribuída ao sistema associada ao cluster Kubernetes habilitado para Azure Arc só é usada pelos agentes do Azure Arc para se comunicar com os serviços do Azure Arc. O certificado associado a essa identidade gerenciada atribuída ao sistema tem uma janela de expiração de 90 dias, e os agentes tentarão renovar esse certificado entre o Dia 46 e o Dia 90. Para evitar que seu certificado de identidade gerenciado expire, certifique-se de que o cluster fique online pelo menos uma vez entre o Dia 46 e o Dia 90 para que o certificado possa ser renovado.

Se o certificado de identidade gerenciado expirar, o recurso será considerado Expired e todos os recursos do Azure Arc (como configuração, monitoramento e política) deixarão de funcionar no cluster.

Para verificar quando o certificado de identidade gerenciado expirará para um determinado cluster, execute o seguinte comando:

az connectedk8s show -n <name> -g <resource-group>

Na saída, o valor do indica quando o certificado de identidade gerenciado expirará (marca 90D managedIdentityCertificateExpirationTime para esse certificado).

Se o valor de indicar um carimbo de managedIdentityCertificateExpirationTime data/hora do passado, o connectivityStatus campo na saída acima será definido como Expired. Nesses casos, para que seu cluster Kubernetes funcione com o Azure Arc novamente:

  1. Exclua o recurso e os agentes do Kubernetes habilitados para Azure Arc no cluster.

    az connectedk8s delete -n <name> -g <resource-group>

  2. Recrie o recurso Kubernetes habilitado para Azure Arc implantando agentes no cluster.

    az connectedk8s connect -n <name> -g <resource-group>

Nota

az connectedk8s delete também excluirá configurações e extensões de cluster na parte superior do cluster. Depois de executar az connectedk8s connecto , recrie as configurações e extensões de cluster no cluster, manualmente ou usando a Política do Azure.

Se eu já estiver usando pipelines de CI/CD, ainda posso usar as configurações do Kubernetes habilitado para Azure Arc ou AKS e GitOps?

Sim, você ainda pode usar configurações em um cluster recebendo implantações por meio de um pipeline de CI/CD. Em comparação com os pipelines tradicionais de CI/CD, as configurações do GitOps apresentam alguns benefícios extras.

Reconciliação de deriva

O pipeline CI/CD aplica alterações apenas uma vez durante a execução do pipeline. No entanto, o operador GitOps no cluster sonda continuamente o repositório Git para buscar o estado desejado dos recursos do Kubernetes no cluster. Se o operador GitOps achar que o estado desejado dos recursos é diferente do estado real dos recursos no cluster, esse desvio será reconciliado.

Aplique GitOps em escala

Os pipelines de CI/CD são úteis para implantações orientadas a eventos para seu cluster Kubernetes (por exemplo, um push para um repositório Git). No entanto, para implantar a mesma configuração em todos os clusters do Kubernetes, você precisa configurar manualmente as credenciais de cada cluster Kubernetes para o pipeline de CI/CD.

Para Kubernetes habilitados para Azure Arc, como o Azure Resource Manager gerencia suas configurações de GitOps, você pode automatizar a criação da mesma configuração em todos os recursos Kubernetes e AKS habilitados para Azure Arc usando a Política do Azure, dentro do escopo de uma assinatura ou de um grupo de recursos. Esse recurso é aplicável até mesmo aos recursos Kubernetes e AKS habilitados para Azure Arc criados após a atribuição da política.

Esse recurso aplica configurações de linha de base (como políticas de rede, associações de função e políticas de segurança de pod) em todo o inventário de cluster do Kubernetes para atender aos requisitos de conformidade e governança.

Conformidade com clusters

O estado de conformidade de cada configuração do GitOps é reportado de volta ao Azure. Isso permite que você acompanhe quaisquer implantações com falha.

O Kubernetes habilitado para Azure Arc armazena dados de clientes fora da região do cluster?

Atualmente, o recurso para permitir o armazenamento de dados de clientes em uma única região está disponível apenas na Região do Sudeste Asiático (Cingapura) do Geo Ásia-Pacífico e na Região Brasil Sul (Estado de São Paulo) do Brasil Geo. Para todas as outras regiões, os dados do cliente são armazenados na Geo. Isso é aplicável às extensões Open Service Mesh habilitadas para Azure Arc e Azure Key Vault Secrets Provider com suporte no Kubernetes habilitado para Azure Arc. Para outras extensões de cluster, consulte a documentação para saber como armazenam dados de clientes. Para obter mais informações, consulte Central de Confiabilidade.

Próximos passos