Implantar o Oracle Kubernetes Engine (OKE) para Produção: Melhores Práticas e Diretrizes

Introdução

Este é o terceiro tutorial em nossa série de automação do Oracle Cloud Infrastructure Kubernetes Engine (OKE), com base nos conceitos introduzidos no segundo tutorial, Implemente o Oracle Cloud Infrastructure Kubernetes Engine (OKE) usando os Módulos Avançados do Terraform. Neste guia, nos concentramos em implantações de OKE prontas para produção e exploramos as principais melhores práticas que melhoram a confiabilidade do cluster, otimizam custos e simplificam as operações. Vamos demonstrar algumas das melhores práticas usando o Terraform, ao mesmo tempo em que destacamos as armadilhas comuns que os usuários encontram ao criar clusters.

Por que a Implantação do OKE em uma VCN Existente é Importante

A criação de um cluster OKE de nível de produção requer um planejamento cuidadoso entre os processos operacionais, de rede e de posicionamento de nós. A implantação em uma VCN (Rede Virtual na Nuvem) existente permite que seu cluster se integre perfeitamente a sub-redes pré-configuradas, tabelas de roteamento e regras de segurança. Isso reduz a sobrecarga operacional, garante a consistência com a infraestrutura da sua organização e permite que várias cargas de trabalho ou clusters coexistam com eficiência na mesma rede.

Os principais parâmetros do Terraform ao implantar em uma VCN existente incluem:

Como alternativa, ao implantar um ambiente totalmente novo do zero, defina is_vcn_created = true para provisionar uma nova rede. Após uma terraform apply bem-sucedida, o Terraform captura os OCIDs da VCN recém-criada e suas sub-redes nas saídas. Esses valores podem ser reutilizados em implantações futuras definindo is_vcn_created = false e fazendo referência aos OCIDs salvos no arquivo terraform.tfvars, permitindo que o Terraform use a rede existente em vez de criar uma nova. A execução de terraform plan nesse estágio confirma que a VCN e as sub-redes atuais são preservadas, evitando alterações desnecessárias na infraestrutura.

Com a base da rede em vigor, este tutorial muda o foco para um conjunto de melhores práticas orientadas para a produção, com o objetivo de tornar os clusters OKE mais resilientes, escaláveis e fáceis de operar. Ao aplicar essas práticas, os clientes podem implantar clusters do OKE altamente disponíveis, econômicos e alinhados com políticas organizacionais, padrões de governança e requisitos operacionais prontos para produção. Faça download do código mais recente aqui oke_advanced_module.zip.

OKE - Melhores Práticas: Diretrizes Prontas para Produção

1. Use o ciclo de nós para fazer upgrade dos pools de nós do OKE.

O ciclo de nós é uma estratégia de upgrade incremental e segura que atualiza imagens de nós, versões do Kubernetes ou configurações do sistema sem interromper as cargas de trabalho. O ciclo de nós é importante porque permite que os clusters evoluam com segurança ao longo do tempo, aplicando patches ou atualizações sem afetar as cargas de trabalho de produção. Para os clientes, isso reduz o risco operacional, garante disponibilidade contínua durante as atualizações e permite que as cargas de trabalho sejam executadas de forma confiável, mantendo as versões mais recentes. O OKE oferece suporte a dois tipos:

Parâmetros como maximum_surge e maximum_unavailable controlam como os upgrades equilibram a velocidade com a disponibilidade. Para atualizações com tempo de inatividade zero, defina maximum_surge = 1 e maximum_unavailable = 0, garantindo que um novo nó fique on-line antes de substituir o antigo. O exemplo a seguir ilustra um exemplo de ciclo de nó com aumento Máximo 1 e Máximo indisponível 0.

OKENodepoolupgraded

Para acionar o upgrade de um cluster existente do OKE que leve ao ciclo do nó:

No arquivo terraform.tfvars:

Depois, execute terraform plan

Você deverá ver uma saída como esta:

Quando você executa terraform apply, o OKE começa a reiniciar os pools de nós um nó de cada vez usando a estratégia BOOT_VOLUME_REPLACE. Nesse modo, somente o volume de inicialização do nó é substituído enquanto a instância de computação subjacente permanece a mesma. Como resultado, o upgrade do nó é executado no local e os atributos de rede, como o endereço IP privado, permanecem inalterados conforme abaixo:

OKEclusterUpgrading OKEclusterUpgrading OKEclusterUpgrading

Para reiniciar nós usando a opção INSTANCE_REPLACE, defina cycle_modes como INSTANCE_REPLACE para que o OKE reinicie os pools de nós um nó por vez. Nesse modo, cada nó é excluído e recriado do zero, incluindo a instância de computação e seu volume de inicialização. Como resultado, o upgrade do nó aplica todos os atributos atualizados, como uma nova versão do Kubernetes ou alterações de forma, mas atributos de rede como o IP privado podem mudar. Essa abordagem garante um nó totalmente atualizado com as configurações mais recentes, fornecendo cobertura máxima de atualização e mantendo a disponibilidade do cluster por meio de substituições contínuas, conforme mostrado abaixo:

OKEclusterUpgrading OKEclusterUpgrading

2. Usar a marcação do OCI em nós de trabalho e balanceadores de carga do OKE para rastrear custos

Ao executar cargas de trabalho do Kubernetes na Oracle Cloud Infrastructure (OCI), é essencial entender de onde vêm seus custos. Marcação é a chave. A OCI permite que você aplique tags definidas e de formato livre a cada recurso, incluindo clusters do OKE, nós de trabalho, balanceadores de carga e volumes persistentes. Isso é importante porque permite relatórios de custos detalhados, auditoria mais fácil e responsabilidade pelo consumo da nuvem. Para os clientes, a marcação fornece insights sobre quais cargas de trabalho consomem mais recursos, melhora a transparência de custos e dá suporte a decisões de otimização para controlar os gastos com a nuvem.

Por que marcar é importante:

# Cluster-level tagging
cluster_freeform_tag_key   = "Environment"
cluster_freeform_tag_value = "Development"

# Node pool-level tagging
node_pool_freeform_tag_key   = "LOB"
node_pool_freeform_tag_value = "DevOps Tech"

# Bastion host tagging
freeform_tags = {
  project     = "devops"
  environment = "production"}

# Defined tagging
defined_tags = { 
  “Corporate_Standard.CostCenter”  = “Finance-123"
  “Corporate_Standard.Environment” = “Production” }

Com essas tags em vigor, você pode gerar relatórios de custos detalhados na OCI Cost Analysis, identificar quais cargas de trabalho estão consumindo a maioria dos recursos e tomar decisões informadas sobre dimensionamento ou otimização.

3. Ponto final, nó, balanceador de carga e sub-redes de pod separados da API (se aplicável).

O design de rede adequado é a melhor prática no OKE porque ele melhora a segurança, o desempenho e a escalabilidade. A segregação de pontos finais de API, nós de trabalho, pods, balanceadores de carga e hosts bastion em sub-redes separadas isola o tráfego crítico, permite tabelas de roteamento personalizadas ou NSGs (Grupos de Segurança de Rede) e impede que um tipo de tráfego interfira em outro. Essa abordagem é essencial para manter uma comunicação segura, um roteamento previsível e um forte isolamento de recursos em ambientes de produção.

Os clientes se beneficiam com um cluster mais seguro, gerenciável e resiliente que pode ser dimensionado com eficiência e lidar com picos de tráfego ou ataques sem afetar as cargas de trabalho. Veja a seguir o trecho de código de terrform.tfvars que permite definir blocos CIDR para sub-redes.

k8apiendpoint_private_subnet_cidr_block       = "REPLACE_WITH_YOUR_CIDR"   # API endpoint subnet
workernodes_private_subnet_cidr_block         = "REPLACE_WITH_YOUR_CIDR"   # Worker nodes subnet
pods_private_subnet_cidr_block                = "REPLACE_WITH_YOUR_CIDR"   # Pod subnet (CNI)
serviceloadbalancers_public_subnet_cidr_block = "REPLACE_WITH_YOUR_CIDR"   # Load balancer subnet
bastion_public_subnet_cidr_block              = "REPLACE_WITH_YOUR_CIDR"   # Bastion host subnet

Seguindo esta prática, você melhora a segurança, simplifica o gerenciamento de rede e torna seu cluster mais resiliente a picos de tráfego ou ataques.

4. Usar um Pool de Nós por Arquitetura de Domínio de Disponibilidade ao usar o Cluster Autoscaler

Na OCI, cada Domínio de Disponibilidade (AD) tem capacidade independente. Embora os pools de nós possam abranger vários ADs para melhorar a alta disponibilidade, isso não é recomendado quando o dimensionador automático do cluster está ativado. O dimensionador automático requer capacidade em todos os ADs selecionados e pode falhar ao dimensionar se algum AD ficar sem recursos.

Para evitar isso, os pools de nós devem ser configurados para usar um único AD quando o dimensionamento automático estiver ativado. Se a capacidade estiver indisponível em um AD, o dimensionador automático poderá dimensionar um pool de nós alternativo em outro AD.

Exemplo de configuração de pool de nós:

availability_domains = [
      "REPLACE_WITH_YOUR_AD"
    ]

Exemplo de configuração do dimensionador automático do cluster:

cluster_autoscaler_config = {
  node_mapping = {
    key = "nodes"
    value = "1:5:ocid1.nodepool....."
  }
}

5. Pools de Nós Separados para Diferentes Requisitos de Carga de Trabalho (x86, ARM, GPU)

Use pools de nós separados para cargas de trabalho que exigem diferentes formas de computação, como x86, ARM ou GPU. Essa abordagem melhora a utilização de recursos, a eficiência da programação e o comportamento de dimensionamento automático, garantindo que cada carga de trabalho seja executada na infraestrutura mais adequada.

Os pods são programados para os pools de nós corretos usando labels de nó, seletores, afinidades ou taints e tolerations, permitindo que o Kubernetes coloque cargas de trabalho em nós com a arquitetura ou os recursos necessários.

Combinando pools de nós dedicados com posicionamento explícito de pods, os clientes obtêm desempenho previsível, dimensionamento eficiente e gerenciamento de cluster simplificado. Neste exemplo, pools de nós separados são criados para formas Intel e AMD, garantindo o posicionamento ideal da carga de trabalho e operações de cluster resilientes.

worker_node_pools = {
  AMD_node_pool = {
    name               = "node_pool_one"                # Node pool name
    shape              = "VM.Standard.E5.Flex"          # Compute shape
    shape_config = {
      memory = 16                                       # Memory (GB)
      ocpus  = 1                                        # OCPUs
    }
    boot_volume_size   = 50                             # Boot volume size (GB)
    operating_system   = "Oracle-Linux"                 # OS for worker nodes
    kubernetes_version = "v1.33"                        # Node Kubernetes version
    source_type        = "IMAGE"                        # Source type for image
    node_labels = {
      Trigger = "Nodes_Cycling_0"                       # Node label
    }
    availability_domains = [                            # Availability_domain setting
      "REPLACE_WITH_YOUR_AD"
    ]                                                   # ADs for node distribution
    number_of_nodes          = 1                        # Number of worker nodes
    pv_in_transit_encryption = false                    # Boot volume in-transit encryption
    node_cycle_config = {
      node_cycling_enabled = true                       # Enable node cycling by default
      maximum_surge        = 1                          # Number of surge nodes
      maximum_unavailable  = 0                          # Max unavailable nodes
      cycle_modes          = ["BOOT_VOLUME_REPLACE"]    # cycle_modes"BOOT_VOLUME_REPLACE" or "INSTANCE_REPLACE"

    }
    ssh_key = "REPLACE_WITH_YOUR_KEY"                   # SSH public key for workers nodes
  }
  Intel_node_pool = {
    name               = "node_pool_two"                # Node pool name
    shape              = "VM.Standard2.8"      	        # Compute shape
    shape_config = {
      memory = 120                                      # Memory (GB)
      ocpus  = 8                                        # OCPUs
    }
    boot_volume_size   = 50                             # Boot volume size (GB)
    operating_system   = "Oracle-Linux"                 # OS for worker nodes
    kubernetes_version = "v1.33"                        # Node Kubernetes version
    source_type        = "IMAGE"                        # Source type for image
    node_labels = {
      Trigger = "Nodes_Cycling_0"                       # Node label
    }
    availability_domains = [                            # Availability_domain setting
      "REPLACE_WITH_YOUR_AD"  
    ]                                                   # ADs for node distribution
    number_of_nodes          = 1                        # Number of worker nodes
    pv_in_transit_encryption = false                    # Boot volume in-transit encryption
    node_cycle_config = {
      node_cycling_enabled = true                       # Enable node cycling by default
      maximum_surge        = 1                          # Number of surge nodes
      maximum_unavailable  = 0                          # Max unavailable nodes
      cycle_modes          = ["BOOT_VOLUME_REPLACE"]    # cycle_modes"BOOT_VOLUME_REPLACE" or "INSTANCE_REPLACE"

    }
    ssh_key = "REPLACE_WITH_YOUR_KEY"                   # SSH public key for workers nodes
  }

}

Após a execução de terraform apply, o cluster do OKE mostrará dois pools de nós separados:

OKEtwonodepools OKEIntelnodepool OKEAMDnodepool

6. Usar Cloud-Init para Personalização de Nó

OS scripts cloud-init são essenciais para automatizar a configuração do nó de trabalho no OKE, garantindo a configuração consistente do sistema operacional, a instalação do pacote e o ajuste do sistema em todos OS nós. A integração do cloud-init com o Terraform permite provisionar nós automaticamente na inicialização, tornando as implantações repetíveis, auditáveis e prontas para produção. Para obter mais informações sobre scripts cloud-init, consulte este documento Using Custom Cloud-init Initialization Scripts to Set Up Managed Nodes.

No código do Terraform fornecido, cada pool de nós faz referência a um script cloud-init usando o parâmetro cloud_init_path. Os clientes podem modificar o conteúdo do cloud-init-general.sh de acordo com os seus requisitos, seguindo as orientações do documento acima. Nesta demonstração, usamos o script de inicialização padrão fornecido na documentação referenciada. Os clientes também podem alterar a localização do script cloud-init atualizando o parâmetro cloud_init_path, conforme mostrado abaixo:

cloud_init_path = "cloud-init-general.sh"

Isso garante que, durante o provisionamento do nó ou o ciclo do nó, cada nó novo ou substituído seja inicializado de forma consistente com a configuração do sistema necessária. Combinado com o Terraform, o cloud-init permite que scripts controlados por versão sejam aplicados automaticamente, eliminando tarefas manuais de pós-provisionamento.

Principais benefícios para nós de trabalho:

7. Aprimorar a Funcionalidade do OKE Usando Complementos

Os complementos do OKE estendem os recursos do cluster para observabilidade, dimensionamento, segurança e gerenciamento de tráfego. Usando o Terraform, você pode ativar ou desativar seletivamente complementos com base nos requisitos de carga de trabalho e minimizar o uso de recursos:

kubernetes_dashboard_enabled       = false
metrics_server_enabled             = false
cluster_autoscaler_enabled         = false
certificate_manager_enabled        = false
istio_enabled                      = false
native_ingress_controller_enabled  = false

Extensões comuns e seus benefícios:

Melhores práticas para complementos:

8. Use a autenticação/descoberta do OIDC se recursos externos precisarem acessar clusters k8s.

Integre a descoberta do OIDC a provedores de identidade externos (como Okta ou Azure AD) se os desenvolvedores ou ferramentas de automação fora da OCI precisarem se autenticar no cluster do Kubernetes. Isso permite o gerenciamento centralizado de identidades e o acesso federado sem a necessidade de gerenciar usuários locais do Kubernetes ou distribuir arquivos kubeconfig. Essa abordagem é especialmente útil quando ferramentas externas de CI/CD, como GitHub Actions, precisam acessar o cluster ou quando as cargas de trabalho dentro do cluster devem ser integradas com segurança a serviços externos, como o HashiCorp Vault. Ao confiar no OIDC, as organizações podem impor políticas de autenticação consistentes, simplificar o gerenciamento de acesso e reduzir a sobrecarga operacional da rotação de credenciais, mantendo fortes limites de segurança.

9. Usar Grupos de Segurança de Rede em vez de Listas de Segurança

Os NSGs (Grupos de Segurança de Rede) são preferidos em relação às Listas de Segurança tradicionais ao proteger clusters do OKE. Os NSGs permitem regras de segurança mais granulares, flexíveis e reutilizáveis que podem ser anexadas diretamente a recursos específicos, como nós de trabalho, balanceadores de carga ou pods. Isso os torna mais adequados para ambientes Kubernetes dinâmicos em que os recursos são dimensionados ou alterados com frequência. Por outro lado, as listas de segurança se aplicam no nível da sub-rede e são projetadas para abranger VCNs ou sub-redes inteiras, o que fornece menos controle ao implementar requisitos de segurança de aplicativo refinados. O uso de NSGs melhora a higiene da segurança, simplifica o gerenciamento de regras e permite um isolamento mais rígido entre os componentes do cluster.

10. Ativar observabilidade com métricas do OCI Logging Analytics e do OKE

Integre o OKE com o OCI Logging Analytics and Monitoring para obter visibilidade profunda do desempenho do cluster e da carga de trabalho. O Logging Analytics fornece agregação avançada de logs, análise e detecção de anomalias, enquanto o Monitoring coleta métricas do plano de controle e dos nós de trabalho do Kubernetes. Juntos, esses serviços permitem que as equipes visualizem tendências, solucionem problemas com mais rapidez e configurem alertas para gerenciamento proativo. Essa solução é particularmente adequada para clientes que procuram uma plataforma de observabilidade nativa da OCI que abstraia as complexidades da ingestão, armazenamento e análise de logs, integrando-se perfeitamente a outros serviços da OCI.

11. Use a identidade da carga de trabalho se os pods precisarem de acesso aos recursos do OCI.

Ao autenticar na OCI, as chaves de API são comumente usadas, mas essas credenciais têm uma vida longa e exigem armazenamento persistente, dificultando o gerenciamento seguro em escala. Embora os controladores de instâncias e recursos melhorem isso ao permitir que instâncias ou serviços de computação assumam sua própria identidade, a Identidade de Carga de Trabalho do OKE estende esse conceito ainda mais, permitindo que pods individuais do Kubernetes assumam sua própria identidade da OCI. Ao ativar a Identidade de Carga de Trabalho do OCI, os pods podem acessar com segurança serviços do OCI, como Armazenamento de Objetos ou Registro em Log, usando políticas do IAM, sem credenciais de codificação rígida ou dependendo de permissões no nível do nó. Isso fornece controle de acesso refinado, auditável e seguro, essencial para ambientes Kubernetes multitenant de nível de produção.

12. Use o tamanho de sub-rede apropriado para nós e pods do OKE.

O planejamento correto de blocos CIDR de sub-rede é uma prática recomendada porque cada nó requer um IP principal e IPs secundários adicionais para pods. Sub-redes pequenas podem levar rapidamente à exaustão de IP, evitando escalonamento ou atualizações. Isso é importante para manter a estabilidade do cluster e apoiar o crescimento. Os clientes se beneficiam ao garantir que os clusters possam ser dimensionados de forma previsível, evitando interrupções operacionais e dando suporte a futuras cargas de trabalho sem exigir o redesenho da rede. Para ambientes de produção, aloque blocos CIDR maiores e consulte o guia de dimensionamento de sub-rede do OKE para garantir que sua VCN possa suportar demandas de carga de trabalho atuais e futuras.

13. Usar o serviço Full Stack Disaster Recovery para fazer backup do cluster k8s

O uso do OCI Full Stack Disaster Recovery para cluster do OKE é uma prática recomendada porque protege a configuração, os aplicativos e a rede do cluster com failover e failback coordenados entre regiões. Isso é importante para a continuidade e a conformidade dos negócios em caso de interrupções regionais ou falhas no sistema. Os clientes se beneficiam de tempo de inatividade reduzido, recuperação rápida e confiança de que as cargas de trabalho de missão crítica permanecem operacionais mesmo durante desastres.

Para obter mais informações, consulte Automatizar Planos de Switchover e Failover para o OCI Kubernetes Engine (com Monitoramento de Estado) com o OCI Full Stack Disaster Recovery

Próximas Etapas:

O Terraform torna o provisionamento do OKE consistente, automatizado e escalável. Seguindo as melhores práticas, como marcação OCI, separação de sub-rede e configuração de nó padronizada, seus clusters permanecem seguros, organizados e transparentes em termos de custo. No próximo blog, vamos nos basear nessas bases para explorar operações orientadas por IA, mostrando como integrar o Oracle AIOps, permitir a observabilidade baseada em IA e criar um modelo de OKE de ponta a ponta para cargas de trabalho de IA. Fique atento à nossa próxima sessão do LiveLabs, na qual você pode obter experiência prática com essas técnicas e experimentar implantações do OKE em um ambiente ao vivo.

Confirmações

Mais Recursos de Aprendizado

Explore outros laboratórios em docs.oracle.com/learn ou acesse mais conteúdo de aprendizado gratuito no canal do Oracle Learning YouTube. Além disso, acesse education.oracle.com/learning-explorer para se tornar um Oracle Learning Explorer.

Para obter a documentação do produto, visite o Oracle Help Center.