Quando você habilita vSphere with Tanzu em clusters vSphere e eles se tornam Supervisors, o plano de controle do Kubernetes é criado dentro da camada do hipervisor. Essa camada contém objetos específicos que permitem executar cargas de trabalho do Kubernetes em ESXi.
O diagrama mostra a arquitetura de alto nível vSphere with Tanzu, com Tanzu Kubernetes Grid na parte superior, o Supervisor no meio, depois ESXi, rede e armazenamento na parte inferior, e vCenter Server gerenciando-os.
Um Supervisor é executado sobre uma camada SDDC que consiste em ESXi para processamento, rede NSX ou VDS e vSAN ou outra solução de armazenamento compartilhado. O armazenamento compartilhado é usado para volumes persistentes para vSphere Pods e VMs em execução dentro do Supervisor, e pods em um cluster Tanzu Kubernetes Grid. Depois que um Supervisor é criado, como administrador do vSphere, você pode criar namespaces no Supervisor que são chamados de vSphere Namespaces. Como engenheiro de DevOps, você pode executar cargas de trabalho que consistem em contêineres em execução dentro do vSphere Pods, implantar VMs e criar clusters do Tanzu Kubernetes Grid.
Você pode implantar um Supervisor em três zonas do vSphere para fornecer alta disponibilidade no nível do cluster que protege suas cargas de trabalho do Kubernetes contra falhas no nível do cluster. Uma zona vSphere é mapeada para um cluster vSphere que você pode configurar como um domínio de falha independente. Em uma implantação de três zonas, todos os três clusters vSphere se tornam um Supervisor. Você também pode implantar um Supervisor em um cluster vSphere, o que criará automaticamente uma Zona vSphere e a mapeará para o cluster, a menos que você use um cluster vSphere que já esteja mapeado para uma zona. Em uma implantação de cluster único, o Supervisor só tem alta disponibilidade no nível do host que é fornecida por vSphere HA.
Em um Supervisor de três zonas, você pode executar cargas de trabalho do Kubernetes em clusters Tanzu Kubernetes Grid e VMs criados usando o serviço de VM. Um Supervisor de três zonas tem os seguintes componentes:
- Supervisor VM do plano de controle. No total, três VMs do plano de controle Supervisor são criadas no Supervisor. Em uma implantação de três zonas, uma VM do plano de controle reside em cada zona. As três VMs do plano de controle Supervisor têm balanceamento de carga, pois cada uma delas tem seu próprio endereço IP. Além disso, um endereço IP flutuante é atribuído a uma das VMs e um quinto endereço IP é reservado para fins de aplicação de patches. vSphere DRS determina o posicionamento exato das VMs do plano de controle na parte dos hosts ESXi do Supervisor e as migra quando necessário.
- Tanzu Kubernetes Grid e API de cluster. Módulos em execução no Supervisor e habilitam o provisionamento e o gerenciamento de clusters do Tanzu Kubernetes Grid.
- Virtual Machine Service. Um módulo responsável por implantar e executar VMs autônomas e VMs que compõem Tanzu Kubernetes Grid clusters.
Um Supervisor implantado em um único cluster vSphere também tem três VMs de plano de controle, que residem na parte dos hosts ESXi do cluster. Em um único cluster Supervisor, você pode executar vSphere Pods além deTanzu Kubernetes Grid clusters e VMs. vSphere DRS é integrado ao Kubernetes Scheduler nas VMs do plano de controle Supervisor, para que DRS determine o posicionamento de vSphere Pods. Quando, como engenheiro de DevOps, você agenda um vSphere Pod, a solicitação passa pelo fluxo de trabalho normal do Kubernetes e depois para DRS, que toma a decisão final de posicionamento.
Devido ao suporte a vSphere Pod, um único cluster Supervisor tem os seguintes componentes adicionais:
- Esfera. Um processo adicional chamado Spherelet é criado em cada host. É um kubelet que é portado nativamente para ESXi e permite que o host ESXi se torne parte do cluster Kubernetes.
- Componente do Container Runtime Executive (CRX). O CRX é semelhante a uma VM da perspectiva do Hostd e do vCenter Server. O CRX inclui um kernel Linux paravirtualizado que funciona em conjunto com o hipervisor. O CRX usa as mesmas técnicas de virtualização de hardware que as VMs e tem um limite de VM ao seu redor. É usada uma técnica de inicialização direta, que permite que o convidado Linux do CRX inicie o processo de inicialização principal sem passar pela inicialização do kernel. Isso permite que o vSphere Pods inicialize quase tão rápido quanto os contêineres.
vSphere Namespace
Um vSphere Namespace define os limites do recurso em que os clusters vSphere Pods, VMs e Tanzu Kubernetes Grid podem ser executados. Quando criado inicialmente, o namespace tem recursos ilimitados no Supervisor. Como administrador do vSphere, você pode definir limites para CPU, memória, armazenamento, bem como o número de objetos Kubernetes que podem ser executados no namespace. As limitações de armazenamento são representadas como cotas de armazenamento no Kubernetes. Um pool de recursos é criado em vSphere por cada namespace no Supervisor.
Em um Supervisor de três zonas, um pool de recursos de namespace é criado em cada cluster vSphere mapeado para uma zona. O namespace se espalha por todos os três clusters vSphere em cada zona. Os recursos utilizados para o namespace em um Supervisor de três zonas são obtidos de todos os três clusters vSphere subjacentes em partes iguais. Por exemplo, se você dedicar 300 MHz de CPU, 100 MHz serão obtidos de cada cluster vSphere.
Para fornecer acesso a namespaces a um engenheiro de DevOps, como administrador do vSphere, você atribui permissão a usuários ou grupos de usuários disponíveis em uma fonte de identidade associada a vCenter Single Sign-On ou de um provedor ODIC registrado no Supervisor.
Depois que um namespace é criado e configurado com limites de recursos e objetos, bem como com permissões e políticas de armazenamento, como engenheiro de DevOps, você pode acessar o namespace para executar cargas de trabalho do Kubernetes e criar clusters Tanzu Kubernetes Grid.
