Compartilhar via

Perguntas frequentes – Kubernetes habilitado para Azure Arc e GitOps

  • Artigo

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

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

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

O Kubernetes habilitado para Azure Arc permite que você estenda as funcionalidades de gerenciamento do Azure (como Azure Monitor e Azure Policy) conectando os clusters do Kubernetes para o Azure. Você mantém o próprio cluster do Kubernetes subjacente.

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

Atualmente, a conexão de um cluster do AKS (Serviço de Kubernetes do Azure) ao Azure Arc não é necessária 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, na parte superior do cluster. Isso pode ser feito usando o recurso de localização personalizada dos Kubernetes habilitados para Azure Arc.

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

A conexão do cluster AKS-HCI ou dos clusters do 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 funcionalidades como a Configuração de Cluster, o Azure Monitor e o Azure Policy (Gatekeeper) para esses clusters do Kubernetes.

Se o cluster do Kubernetes habilitado para o 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 sem nenhum custo.

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

A identidade gerenciada atribuída pelo sistema associada ao seu cluster de Kubernetes habilitado para o 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 pelo sistema tem um período de validade de 90 dias e os agentes vão tentar renovar o certificado entre o dia 46 até o dia 90. Para evitar que o certificado de identidade gerenciada 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 gerenciada 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 gerenciada está prestes a expirar para um cluster específico, execute o seguinte comando:

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

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

Se o valor de managedIdentityCertificateExpirationTime indicar um carimbo de data/hora do passado, então o campo connectivityStatus na saída acima será definida como Expired. Nesses casos, para que o cluster do Kubernetes volte a funcionar com o Azure Arc:

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

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

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

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

Observação

az connectedk8s delete também excluirá as configurações e extensões de cluster na parte superior do cluster. Após a execução de az connectedk8s connect, recrie as configurações e extensões de cluster no cluster, manualmente ou usando o Azure Policy.

Se já estiver usando pipelines de CI/CD, ainda poderei usar as configurações e o Kubernetes habilitados para o Azure Arc ou AKS e GitOps?

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

Reconciliação de descompasso

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

Aplicar GitOps em escala

Os pipelines de CI/CD são úteis para implantações controladas por eventos no seu cluster do Kubernetes (por exemplo, um push para um repositório Git). No entanto, para implantar a mesma configuração em todos os seus clusters do Kubernetes, será necessário configurar manualmente cada credencial do cluster do Kubernetes para o pipeline de CI/CD.

Para o Kubernetes habilitado para o 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 do Kubernetes habilitados para o Azure Arc e AKS usando o Azure Policy, dentro do escopo de uma assinatura ou de um grupo de recursos. Essa funcionalidade é ainda aplicável aos recursos do Kubernetes habilitados para Azure Arc e AKS 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 do cluster

O estado de conformidade de cada configuração de GitOps é relatado de volta ao Azure. Isso permite controlar todas as implantações com falha.

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

O recurso para habilitar o armazenamento de dados do cliente em apenas uma região está disponível atualmente apenas na região do Sudeste da Ásia (Singapura), na área geográfica do Pacífico Asiático e na região Sul do Brasil (Estado de São Paulo). Para todas as outras regiões, os dados do cliente são armazenados na Área geográfica. Isso se aplica às extensões do Provedor de Segredos do Azure Key Vault e da Malha de Serviço Aberta habilitada para o Azure Arc com suporte no Kubernetes habilitado para o Azure Arc. Para outras extensões de cluster, veja a documentação para saber como elas armazenam dados do cliente. Para obter mais informações, confira Central de Confiabilidade.

Próximas etapas