O GKE no VMware é executado no seu local em um ambiente vSphere. Neste documento, descrevemos os requisitos do seu ambiente do vSphere.
Compatibilidade de versões
Os requisitos do vSphere variam de acordo com a versão do GKE no VMware que você está usando. Para mais informações, consulte a matriz de compatibilidade de versões para versões totalmente compatíveis e versões anteriores.
Versões compatíveis
O vSphere é o software de virtualização de servidores da VMware. O vSphere inclui o ESXi e o vCenter Server.
O GKE no VMware oferece suporte a estas versões do ESXi e do vCenter Server
- 7.0 Atualizar a versão 2 e atualizações mais recentes da versão 7.0
- 8.0 (Prévia)
Recomendamos que você use a versão 7.0, atualização 3 ou uma atualização posterior da versão 7.0.
Se você quiser criar instantâneos de volume CSI, será necessário ter uma das seguintes versões:
- 7.0 Atualização 3 ou uma atualização posterior da versão 7.0
- 8.0
Requisitos de licença
Você precisa ter uma destas licenças:
Licença da vSphere Enterprise Plus Além dessa licença, você precisa ter uma assinatura de suporte válida.
Licença vSphere Standard. Além dessa licença, você precisa ter uma assinatura de suporte válida. Com essa licença, não é possível ativar grupos de antiafinidade. Além disso, não é possível especificar seu próprio pool de recursos. Use o pool de recursos padrão.
Requisitos de hardware
O GKE no VMware é executado em um conjunto de hosts físicos que executam o hipervisor ESXi da VMware. Para saber mais sobre os requisitos de hardware do ESXi, consulte Requisitos de hardware do ESXi (em inglês).
Para ambientes de produção, recomendamos o seguinte:
Tenha pelo menos quatro hosts ESXi disponíveis para as VMs do cluster.
Ative o tráfego de Cópia de arquivo de rede (NFC, na sigla em inglês) entre os hosts ESXi para permitir o compartilhamento de modelos do SO se você quiser implantar clusters do Anthos no VMware em diferentes clusters ou pools de recursos do vSphere no mesmo data center do vSphere.
Defina
antiAffinityGroups.enabled
comotrue
nos arquivos de configuração do cluster.
Se você definir antiAffinityGroups.enabled
como true
, o GKE no VMware vai criar regras antiafinidade do DRS para os nós do cluster, fazendo com que eles sejam
propagados por pelo menos três hosts ESXi físicos. Mesmo que as regras do DRS exijam que os nós de cluster sejam propagados por três hosts ESXi, recomendamos que pelo menos quatro hosts ESXi estejam disponíveis. Isso protege o plano de controle do cluster contra perda. Por exemplo, suponha que haja apenas
três hosts ESXi e que o nó do plano de controle
do cluster de administrador esteja em um host ESXi que falha. A regra do DRS vai impedir que o
nó do plano de controle seja colocado em um dos dois hosts ESXi restantes.
Para avaliação e prova de conceito, é possível definir antiAffinityGroups.enabled
como false
e usar apenas um host ESXi. Para mais informações, consulte
Configurar infraestrutura mínima.
Privilégios da conta de usuário do vCenter
Para configurar um ambiente do vSphere, um administrador da organização pode optar por usar uma conta de usuário do vCenter que tenha o papel de administrador do vCenter Server. Este papel fornece acesso total a todos os objetos do vSphere.
Após a configuração do ambiente do vSphere, um administrador de cluster pode criar clusters de administrador e de usuário. O administrador do cluster não precisa de todos os privilégios fornecidos pelo papel de Administrador do vCenter Server.
Quando um administrador ou desenvolvedor de cluster cria um cluster, ele fornece uma conta de usuário do vCenter em um arquivo de configuração de credenciais. Recomendamos que a conta de usuário do vCenter listada em um arquivo de configuração de credenciais seja atribuída a um ou mais papéis personalizados que tenham os privilégios mínimos exigidos para a criação e o gerenciamento de clusters.
O administrador da organização pode seguir duas abordagens diferentes:
Criar vários papéis com diferentes graus de privilégio. Em seguida, criar permissões que atribuam esses papéis limitados a um usuário ou grupo em objetos individuais do vSphere.
Criar um papel que tenha todos os privilégios necessários. Em seguida, criar uma permissão global que atribua esse papel a um usuário ou grupo específico em todos os objetos nas hierarquias do vSphere.
Recomendamos a primeira abordagem, porque ela limita o acesso e aumenta a segurança do ambiente do vCenter Server. Para mais informações, consulte Como usar papéis para atribuir privilégios e Práticas recomendadas para papéis e permissões
Para informações sobre como usar a segunda abordagem, consulte Criar uma permissão global.
A tabela a seguir mostra quatro papéis personalizados que um administrador da organização pode criar. Em seguida, o administrador pode usar os papéis personalizados para atribuir permissões em objetos específicos do vSphere:
Função personalizada | Privilégios | Objetos | Propagar para objetos filhos? |
---|---|---|---|
ClusterEditor |
System.Read System.View System.Anonymous Host.Inventory.Modificar cluster |
cluster | Sim |
SessionValidator |
System.Read System.View System.anonymous Sessão Sessions.Validate Cns.Searchable Armazenamento orientado por perfis.Visualização de armazenamento orientado por perfis |
Servidor vCenter raiz | Não |
ReadOnly |
System.Read System.View System.Anonymous |
data center rede |
Sim |
Anthos | Privilégios no papel do Anthos |
datastore pool de recursos pasta da VM rede |
Sim |
Privilégios na função personalizada do Anthos
Criar funções e permissões personalizadas
Um administrador da organização pode usar a ferramenta de linha de comando govc para criar funções e permissões personalizadas.
O administrador da organização precisa ter uma conta do vCenter Server que tenha privilégios suficientes para criar funções e permissões. Por exemplo, uma conta que tem o papel de administrador é adequada.
Antes de executar govc
, defina algumas variáveis de ambiente:
Defina GOVC_URL como o URL da sua instância do vCenter Server.
Defina GOVC_USERNAME como o nome de usuário da conta do vCenter Server do administrador da organização.
Defina GOVC_PASSWORD como a senha da conta do vCenter Server do administrador da organização.
Exemplo:
export GOVC_URL=vc-01.example export GOVC_USERNAME=alice@vsphere.local export GOVC_PASSWORD=8ODQYHo2Yl@
Criar funções personalizadas
Crie as funções personalizadas ClusterEditor, SessionValidator e ReadOnly:
govc role.create ClusterEditor System.Read System.View System.Anonymous Host.Inventory.EditCluster govc role.create SessionValidator System.Read System.View System.Anonymous Sessions.ValidateSession Cns.Searchable StorageProfile.View govc role.create ReadOnly System.Read System.View System.Anonymous
Crie uma permissão que conceda o papel ClusterEditor
Uma permissão pega um par (usuário, papel) e o associa a um objeto. Ao
atribuir uma permissão a um objeto, é possível especificar se ela
será propagada para objetos filhos. Com govc
, você faz isso definindo a
sinalização --propagate
como true
ou false
. O padrão é false
.
Crie uma permissão que conceda o papel ClusterEditor a um usuário em um objeto de cluster. Essa permissão é propagada para todos os objetos filhos do objeto de cluster:
govc permissions.set -principal ACCOUNT \ -role ClusterEditor -propagate=true CLUSTER_PATH`
Substitua:
ACCOUNT: a conta de usuário do vCenter Server que está recebendo o papel
CLUSTER_PATH: o caminho do cluster na hierarquia de objetos do vSphere
Por exemplo, o comando a seguir cria uma permissão que associa o par (bob@vsphere.local, ClusterEditor a my-dc/host/my-cluster). A permissão é propagada a todos os objetos filhos de my-dc/host/my-cluster:
govc permissions.set -principal bob@vsphere.local \ -role ClusterEditor -propagate=true my-dc/host/my-cluster
Criar permissões adicionais
Esta seção fornece exemplos de criação de permissões adicionais. Substitua os caminhos de objeto de exemplo conforme necessário para seu ambiente.
Crie uma permissão que conceda o papel SessionValidator a uma conta no objeto raiz do vCenter Server. Essa permissão não se propaga a objetos filhos:
govc permissions.set -principal ACCOUNT \ -role SessionValidator -propagate=false
Crie permissões que concedam o papel ReadOnly a uma conta em um objeto de data center e um objeto de rede. Essas permissões se propagam a objetos filhos:
govc permissions.set -principal ACCOUNT \ -role ReadOnly -propagate=true \ /my-dc \ /my-dc/network/my-net
Crie permissões que concedam o papel do Anthos a uma conta em quatro objetos: um datastore, uma pasta de VM, um pool de recursos e uma rede. Essas permissões são propagadas a objetos filhos:
govc permissions.set -principal ACCOUNT -role Anthos -propagate=true \ /my-dc/datastore/my-ds \ /my-dc/vm/my-folder \ /my-dc/host/my-cluster/Resources/my-rp \ /my-dc/network/my-net
Criar uma permissão global
Nesta seção, você verá uma alternativa à criação de vários papéis e várias permissões. Não recomendamos essa abordagem porque ela concede um grande conjunto de privilégios em todos os objetos nas hierarquias do vSphere.
Se você ainda não criou a função personalizada do Anthos, crie-a agora.
Criar uma permissão global:
govc permissions.set -principal ACCOUNT \ -role Anthos -propagate=true
Substitua:
Substitua ACCOUNT pela conta de usuário do vCenter Server que está recebendo o papel
Por exemplo, o comando a seguir cria uma permissão global que concede o papel do Anthos a bob@vsphere.local. A permissão é propagada a todos os objetos nas hierarquias do vSphere:
govc permissions.set -principal bob@vsphere.local -role Anthos -propagate=true
Problemas conhecidos
Consulte O instalador falha ao criar o vSphere datadisk.
A seguir
Requisitos de CPU, RAM e armazenamento