|
Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official. |
Referência de Configuração do Cluster GKE
Localização do Cluster
| Valor | Descrição |
|---|---|
Tipo de Localização |
Zonal ou Regional. Com o GKE, você pode criar um cluster adaptado aos requisitos de disponibilidade da sua carga de trabalho e ao seu orçamento. Por padrão, os nós de um cluster são executados em uma única zona de computação. Quando várias zonas são selecionadas, os nós do cluster se espalharão por várias zonas de computação, enquanto o plano de controle estará localizado em uma única zona. Clusters regionais aumentam a disponibilidade do plano de controle também. Para ajuda na escolha do tipo de disponibilidade do cluster, consulte estes documentos. |
Zona |
Cada região no Compute Engine contém várias zonas. Para mais informações sobre regiões e zonas disponíveis, consulte estes documentos. |
Zonas Adicionais |
Para clusters zonais, você pode selecionar zonas adicionais para criar um cluster multi-zona. |
Região |
Para clusters regionais,, você pode selecionar uma região. Para mais informações sobre regiões e zonas disponíveis, consulte esta seção. A primeira parte do nome de cada zona é o nome da região. |
Opções do Cluster
Kubernetes Version
Mutável: sim
Para mais informações sobre versões do GKE Kubernetes, consulte estes documentos.
Faixa de Endereço do Contêiner
Mutável: não
A faixa de endereços IP para pods no cluster. Deve ser uma faixa CIDR válida, por exemplo, 10.42.0.0/16. Se não especificado, uma faixa aleatória é escolhida automaticamente de 10.0.0.0/8 e excluirá faixas já alocadas para VMs, outros clusters ou rotas. Faixas escolhidas automaticamente podem entrar em conflito com endereços IP reservados, rotas dinâmicas ou rotas dentro de VPCs que estão conectadas ao cluster.
Rede
Mutável: não
A Rede do Compute Engine à qual o cluster se conecta. Rotas e gateways de segurança serão criados usando esta rede. Se estiver usando VPCs Compartilhadas, as redes VPC que são compartilhadas com seu projeto aparecerão aqui e estarão disponíveis para seleção neste campo. Para obter mais informações, consulte esta página.
Sub-rede do Nó / Sub-rede
Mutável: não
A sub-rede do Compute Engine à qual o cluster se conecta. Esta sub-rede deve pertencer à rede especificada no campo Rede. Selecione uma sub-rede existente ou selecione "Criar Sub-rede Automaticamente" para que uma seja criada automaticamente. Se não estiver usando uma rede existente, Nome da Sub-rede é necessário para gerar uma. Se estiver usando VPCs Compartilhadas, as sub-redes VPC que são compartilhadas com seu projeto aparecerão aqui. Se estiver usando uma rede VPC compartilhada, você não pode selecionar "Criar sub-rede automaticamente". Para obter mais informações, consulte esta página.
Nome da sub-rede
Mutável: não
Criar automaticamente uma sub-rede com o nome fornecido. Necessário se "Criar sub-rede automaticamente" estiver selecionado para Node Subnet ou Subnet. Para mais informações sobre sub-redes, consulte esta página.
Álias de IP
Mutável: não
Ativar IPs de alias. Isso habilita o roteamento de tráfego nativo do VPC. Necessário se estiver usando VPCs Compartilhadas.
Política de Rede
Mutável: sim
Ativar a aplicação de políticas de rede no cluster. Uma política de rede define o nível de comunicação que pode ocorrer entre pods e serviços no cluster. Para mais informações, consulte esta página.
Isolamento de Rede do Projeto
Mutável: sim
Escolha se deseja habilitar ou desabilitar a comunicação entre projetos.
Clusters Importados
Para clusters importados, a Isolação de Rede de Projeto (PNI) requer que a Política de Rede do Kubernetes esteja habilitada no cluster previamente. Para clusters criados pelo Rancher, o Rancher habilita automaticamente a Política de Rede do Kubernetes.
-
No GKE, habilite a Política de Rede no nível do cluster. Consulte o guia oficial do GKE para instruções.
-
Após habilitar a Política de Rede, importe o cluster para o Rancher e habilite o PNI para isolamento em nível de projeto.
Bloco CIDR Ipv4 do Nó
Mutável: não
O intervalo de endereços IP dos IPs de instância neste cluster. Pode ser definido se "Criar sub-rede automaticamente" estiver selecionado para Node Subnet ou Subnet. Deve ser um intervalo CIDR válido, por exemplo, 10.96.0.0/14. Para mais informações sobre como determinar o intervalo de endereços IP, consulte esta página.
Nome do Intervalo Secundário do Cluster
Mutável: não
O nome de um intervalo secundário existente para endereços IP de Pods. Se selecionado, o Intervalo de Endereços de Pods do Cluster será preenchido automaticamente. Obrigatório se estiver usando uma rede VPC compartilhada.
Intervalo de Endereços de Pods do Cluster
Mutável: não
O intervalo de endereços IP atribuído aos pods no cluster. Deve ser um intervalo CIDR válido, por exemplo, 10.96.0.0/11. Se não fornecido, será criado automaticamente. Deve ser fornecido se estiver usando uma rede VPC compartilhada. Para mais informações sobre como determinar o intervalo de endereços IP para seus pods, consulte esta seção.
Nome do Intervalo Secundário de Serviços
Mutável: não
O nome de um intervalo secundário existente para endereços IP de serviços. Se selecionado, o Intervalo de Endereços de Serviços será preenchido automaticamente. Obrigatório se estiver usando uma rede VPC compartilhada.
Intervalo de Endereços de Serviços
Mutável: não
O intervalo de endereços atribuído aos serviços no cluster. Deve ser um intervalo CIDR válido, por exemplo, 10.94.0.0/18. Se não fornecido, será criado automaticamente. Deve ser fornecido se estiver usando uma rede VPC compartilhada. Para mais informações sobre como determinar o intervalo de endereços IP para seus serviços, consulte esta seção.
Cluster Privado
Mutável: não
|
Clusters privados requerem planejamento e configuração adicionais fora do Rancher. Consulte o guia do cluster privado. |
Atribua apenas endereços IP internos aos nós. Os nós do cluster privado não podem acessar a internet pública, a menos que etapas adicionais de rede sejam tomadas no GCP.
Ativar Endpoint Privado
|
Clusters privados requerem planejamento e configuração adicionais fora do Rancher. Consulte o guia do cluster privado. |
Mutável: não
Restringe o acesso externo ao endpoint do plano de controle. Disponível apenas se Cluster Privado também estiver selecionado. Se selecionado, e se o Rancher não tiver acesso direto à rede da nuvem privada virtual em que o cluster está sendo executado, o Rancher fornecerá um comando de registro para ser executado no cluster para permitir que o Rancher se conecte a ele.
Rede Autorizada do Mestre
Mutável: sim
Ative redes autorizadas do plano de controle para bloquear IPs de origem não confiáveis e não-GCP de acessar o mestre do Kubernetes via HTTPS. Se selecionado, redes autorizadas adicionais podem ser adicionadas. Se o cluster for criado com um endpoint público, esta opção é útil para restringir o acesso ao endpoint público apenas a certas redes, como a rede onde seu serviço Rancher está sendo executado. Se o cluster tiver apenas um endpoint privado, esta configuração é obrigatória.
Opções adicionais
Complementos do Cluster
Componentes adicionais do cluster Kubernetes. Para mais informações, consulte esta página.
Escalonamento Horizontal de Pods
Mutável: sim
O Autoscaler Horizontal de Pods altera a forma da sua carga de trabalho Kubernetes, aumentando ou diminuindo automaticamente o número de Pods em resposta ao consumo de CPU ou memória da carga de trabalho, ou em resposta a métricas personalizadas relatadas de dentro do Kubernetes ou métricas externas de fontes fora do seu cluster. Para mais informações, consulte esta página.
Balanceamento de Carga HTTP (L7)
Mutável: sim
O Balanceamento de Carga HTTP (L7) distribui o tráfego HTTP e HTTPS para backends hospedados no GKE. Para mais informações, consulte esta página.
Recursos do Cluster (Recursos Alfa)
Mutável: não
Ativa todos os grupos e recursos da API alpha do Kubernetes para o cluster. Quando habilitado, o cluster não pode fazer upgrade e será excluído automaticamente após 30 dias. Clusters alpha não são recomendados para uso em produção, pois não estão cobertos pelo SLA do GKE. Para mais informações, consulte esta página.
Serviço de Registro
Mutável: sim
O serviço de registro que o cluster usa para gravar logs. Use Cloud Logging ou nenhum serviço de registro, caso em que nenhum log é exportado do cluster.
Serviço de Monitoramento
Mutável: sim
O serviço de monitoramento que o cluster usa para gravar métricas. Use Cloud Monitoring ou nenhum serviço de monitoramento, caso em que nenhuma métrica é exportada do cluster.
Maintenance Window
Mutável: sim
Defina a hora de início para uma janela de manutenção de 4 horas. A hora é especificada no fuso horário UTC usando o formato HH:MM. Para mais informações, consulte esta página.
Pools de Nós
Nesta seção, insira detalhes descrevendo a configuração de cada nó no pool de nós.
Kubernetes Version
Mutável: sim
A versão do Kubernetes para cada nó no pool de nós. Para mais informações sobre versões do GKE Kubernetes, consulte estes documentos.
Tipo de Imagem
Mutável: sim
A imagem do sistema operacional do nó. Para mais informações sobre as opções de imagem de nó que o GKE oferece para cada SO, consulte esta página.
|
A opção padrão é "SO Otimizado para Contêiner com Docker". O sistema de arquivos somente leitura no SO Otimizado para Contêiner do GCP não é compatível com a implementação de xref:[registro legado] no Rancher. Se você precisar usar o recurso de registro legado, selecione "Ubuntu com Docker" ou "Ubuntu com Containerd". O recurso de registro atual é compatível com a imagem do SO Otimizado para Contêiner. |
|
Se selecionar "Canal de Serviço de Longo Prazo do Windows" ou "Canal Semestral do Windows" para o tipo de imagem do pool de nós, você também deve adicionar pelo menos um pool de nós do SO Otimizado para Contêiner ou Ubuntu. |
Tipo de Máquina
Mutável: não
Os recursos de hardware virtualizados disponíveis para as instâncias de nó. Para mais informações sobre os tipos de máquinas do Google Cloud, consulte esta página.
Tipo de Disco Raiz
Mutável: não
Os discos persistentes padrão são suportados por discos rígidos padrão (HDD), enquanto os discos persistentes SSD são suportados por unidades de estado sólido (SSD). Para mais informações, consulte esta seção.
Discos SSD Locais
Mutável: não
Configure o armazenamento do disco SSD local de cada nó em GB. Os SSDs locais estão fisicamente conectados ao servidor que hospeda sua instância de VM. Os SSDs locais têm maior taxa de transferência e menor latência do que os discos persistentes padrão ou os discos persistentes SSD. Os dados que você armazena em um SSD local persistem apenas até que a instância seja parada ou excluída. Para mais informações, consulte esta seção.
Nós Preemptíveis (beta)
Mutável: não
Nós preemptíveis, também chamados de VMs preemptíveis, são instâncias de VM do Compute Engine que duram no máximo 24 horas em geral e não oferecem garantias de disponibilidade. Para mais informações, consulte esta página.
Taints
Mutável: não
Quando você aplica uma taint a um nó, apenas os Pods que toleram a taint são permitidos a rodar no nó. Em um cluster GKE, você pode aplicar uma taint a um pool de nós, o que aplica a taint a todos os nós do pool.
Rótulos de Nó
Mutável: não
Você pode aplicar rótulos ao pool de nós, o que aplica os rótulos a todos os nós do pool.
Rótulos inválidos podem impedir a realização de um fazer upgrade ou impedir que o Rancher seja iniciado. Para detalhes sobre os requisitos de sintaxe de rótulos, consulte a documentação do Kubernetes.
Tags de Rede
Mutável: não
Você pode adicionar tags de rede ao pool de nós para criar regras de gateway de segurança e rotas entre sub-redes. As tags se aplicarão a todos os nós do pool.
Para detalhes sobre a sintaxe e os requisitos das tags, consulte a documentação do Kubernetes.
Detalhes do Grupo
Nesta seção, insira detalhes descrevendo o pool de nós.
Contagem Inicial de Nós
Mutável: sim
Número inteiro para a quantidade inicial de nós no pool de nós.
Máximo de Pods por Nó
Mutável: não
O GKE tem um limite rígido de 110 Pods por nó. Para mais informações sobre os limites do Kubernetes, veja esta seção.
Escalonamento Automático
Mutável: sim
O escalonamento automático do pool de nós cria ou exclui nós dinamicamente com base nas demandas da sua carga de trabalho. Para mais informações, consulte esta página.
Reparo Automático
Mutável: sim
O recurso de auto-reparo de nós do GKE ajuda a manter os nós em seu cluster em um estado saudável e em execução. Quando ativado, o GKE faz verificações periódicas no estado de saúde de cada nó em seu cluster. Se um nó falhar em verificações de saúde consecutivas por um período prolongado, o GKE inicia um processo de reparo para esse nó. Para mais informações, consulte a seção sobre reparo automático de nós.
Fazer Upgrade Automático
Mutável: sim
Quando ativada, a funcionalidade de fazer upgrade automático mantém os nós em seu cluster atualizados com a versão do plano de controle do cluster (mestre) quando este é atualizado em seu nome. Para mais informações sobre o processo de fazer upgrade automático dos nós, consulte esta página.
Escopos de Acesso
Mutável: não
Os escopos de acesso são o método legado de especificar permissões para seus nós.
-
Permitir acesso padrão: O acesso padrão para novos clusters é a conta de serviço padrão do Compute Engine.
-
Permitir acesso total a todas as APIs da Nuvem: Geralmente, você pode apenas definir o escopo de acesso da plataforma de nuvem para permitir acesso total a todas as APIs da Nuvem, e então conceder à conta de serviço apenas os papéis IAM relevantes. A combinação de escopos de acesso concedidos à instância da máquina virtual e os papéis IAM concedidos à conta de serviço determina a quantidade de acesso que a conta de serviço tem para essa instância.
-
Definir acesso para cada API: Alternativamente, você pode optar por definir escopos específicos que permitem acesso aos métodos de API particulares que o serviço chamará.
Para mais informações, consulte a seção sobre como habilitar contas de serviço para uma VM.
Configurando o Intervalo de Atualização
O intervalo de atualização pode ser configurado através da configuração "gke-refresh", que é um inteiro representando segundos.
O valor padrão é 300 segundos.
O intervalo de sincronização pode ser alterado executando kubectl edit setting gke-refresh.
Quanto menor a janela de atualização, menor a probabilidade de ocorrerem condições de corrida, mas isso aumenta a probabilidade de encontrar limites de solicitação que podem estar em vigor para as APIs do GCP.