Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo descreve os principais conceitos de um Nexus Azure Kubernetes Service Cluster, um Serviço Kubernetes do Azure gerenciado que você pode usar para implantar e operar aplicativos em contêineres na Plataforma Azure Operator Nexus
O que é o Kubernetes?
O Kubernetes é uma plataforma em rápida evolução que gerencia aplicativos baseados em contêiner e seus componentes de rede e armazenamento associados. O Kubernetes se concentra nas cargas de trabalho do aplicativo, não nos componentes de infraestrutura subjacentes. Ele fornece uma abordagem declarativa para implantações, apoiada por um conjunto robusto de APIs para operações de gerenciamento. Consulte O que é o Kubernetes para saber mais sobre o Kubernetes.
Serviço Nexus Kubernetes
O Nexus Kubernetes Cluster Service é uma distribuição do Kubernetes projetada para implantação local em instâncias do Nexus. Ele simplifica a criação automatizada de contêineres e é otimizado para executar cargas de trabalho associadas a funções de rede com uso intensivo de dados.
Como qualquer cluster Kubernetes, o cluster Nexus Kubernetes tem dois componentes:
Plano de controle: fornece os principais serviços do Kubernetes e gerencia o ciclo de vida das cargas de trabalho dos aplicativos.
Para executar os seus aplicativos e serviços de suporte, precisa de um nó Kubernetes. Fornece o ambiente de execução de contentores. Cada cluster Nexus AKS tem pelo menos um nó. Node é hospedado na máquina virtual (VM) que executa os componentes do nó Kubernetes. A VM é criada como parte da implantação do cluster Nexus AKS na instância do Nexus. Há dois tipos de pools de nós no Nexus Kubernetes Clusters
- Ao criar um cluster Nexus AKS, você define o número inicial de nós e seu tamanho (SKU), o que cria um pool de nós do sistema. Os pools de nós do sistema hospedam pods críticos do sistema.
- Por outro lado, para dar suporte a aplicativos que têm diferentes demandas de computação ou armazenamento, você pode criar pools de nós de usuário, também conhecidos como pool de Agente Nexus. Cada VM em um pool do Nexus Agent adere a uma configuração uniforme, como CPU, memória, disco e assim por diante. Depois que um pool de agentes é estabelecido, o número de VMs dentro dele permanece fixo. Para dimensionar a capacidade de um cluster Nexus Kubernetes, mais pools de agentes podem ser criados e integrados ao cluster existente. Em outras palavras, o pool do Nexus Agent suporta dimensionamento horizontal permitindo a adição ou remoção de pools de Agentes dentro do cluster Nexus Kubernetes.
No entanto, os pods de aplicação podem ser agendados em pools de nós do sistema, caso o utilizador deseje ter apenas um pool de nós no seu cluster. Cada cluster Nexus Kubernetes deve conter pelo menos um pool de nós do sistema com pelo menos um nó.
Recursos do Nexus Kubernetes Cluster
Os Recursos de Cluster do Nexus Kubernetes, anteriormente conhecidos como "Complementos" em versões anteriores ao Azure Operator Nexus versão 3.11.0, são um componente da plataforma Nexus que permite que os clientes aprimorem seus clusters Nexus Kubernetes com pacotes ou componentes extras. Os recursos são categorizados em dois tipos: obrigatório e opcional.
Recursos necessários: os recursos necessários são implantados automaticamente em clusters Nexus Kubernetes provisionados. Recursos principais como Calico, MetalLB, Nexus Storage CSI, plug-ins IPAM, metrics-server, node-local-dns, Arc for Kubernetes e Arc for Servers são incluídos por padrão quando clusters são criados. A conclusão bem-sucedida do processo de provisionamento de cluster depende da instalação bem-sucedida desses recursos. Se uma instalação de recurso necessária falhar e não puder ser corrigida, o status do cluster será marcado como falha.
Recursos opcionais: Recursos opcionais são serviços suplementares associados a um recurso de cluster do Kubernetes. Os clientes podem optar por ativar ou desativar esses recursos sob demanda. Exemplo de serviços suplementares poderia incluir a implantação de registro de cache de imagem local no nível de cluster dentro do cluster Nexus AKS para oferecer suporte a cenários desconectados. O Nexus AKS permite que o cliente observe o status, a integridade e a versão de cada recurso necessário e opcional, que pode ser monitorado no portal do Azure ou o estado pode ser obtido usando APIs do Azure Resource Manager.
Os recursos são instalados uma vez e só podem ser atualizados ou melhorados quando o cliente atualiza o cluster Nexus Kubernetes. Permite aos clientes aplicarem hotfixes críticos de produção sem interferência das operações de infraestrutura subjacentes, que de outra forma poderiam sobregravar as suas modificações de cluster.
Nexus Zonas Disponíveis
O Nexus suporta o conceito de uma zona de disponibilidade. Uma zona de disponibilidade é delineada no nível do rack e permite que os clientes distribuam suas cargas de trabalho por várias zonas para obter alta disponibilidade. Para uma instância do Nexus com oito racks, os clientes obtêm oito zonas de disponibilidade para distribuir sua carga de trabalho. Isso é configurado dentro do plano de controle e da configuração do pool de agentes para um determinado cluster Nexus AKS.
Cada zona compreende um par de servidores de gerenciamento com redundância e uma coleção de servidores de computação que funcionam como um pool de recursos. Durante implantações de vários racks no Nexus e ao realizar upgrades de pacotes em execução, as zonas de disponibilidade oferecem o benefício adicional de atuar como um domínio de atualização. Isso garante que, no máximo, apenas os servidores dentro de um único rack sejam colocados offline para essas atualizações.
Domínio de falha
O operador Nexus garante que os nós do Nexus Kubernetes Cluster sejam distribuídos entre domínios de atualização. Esta distribuição é feita de forma a melhorar a resiliência e a disponibilidade do cluster. O operador Nexus usa regras de afinidade do Kubernetes para agendar nós em zonas específicas. Ele garante que as VMs subjacentes não sejam colocadas no mesmo servidor físico ou no mesmo domínio de atualização, melhorando a tolerância a falhas do cluster.