Configuração do Recurso de Rede para Criação e Implantação de Cluster
Descubra como configurar recursos de rede para usar o Kubernetes Engine (OKE).
Antes de usar o Kubernetes Engine, crie e implemente clusters nas regiões de uma tenancy:
- Na tenancy, já deverá haver um compartimento para conter os recursos de rede necessários (como VCN, sub-redes, gateway de Internet, tabela de roteamento, grupos de segurança de rede e/ou listas de segurança). Se esse compartimento ainda não existir, você terá que criá-lo. Observe que os recursos da rede podem residir no compartimento raiz. Porém, se você espera que várias equipes criem clusters, a melhor prática é criar um compartimento separado para cada equipe.
- No compartimento, os recursos de rede (como VCN, sub-redes, gateway de internet, tabela de roteamento, grupos de segurança de rede e/ou listas de segurança) devem ser configurados adequadamente em cada região na qual você deseja criar e implantar clusters. Ao criar um novo cluster, você pode fazer com que o Kubernetes Engine crie e configure automaticamente novos recursos de rede no workflow 'Criação Rápida'. Se preferir, especifique explicitamente os recursos de rede existentes a serem usados para o workflow 'Criação Personalizada'. Caso especifique recursos de rede existentes, você ou outra pessoa já deverá ter configurado esses recursos de forma apropriada, conforme descrito neste tópico.
Este tópico descreve a configuração necessária para cada recurso de rede. Para ver detalhes de uma configuração típica, consulte Exemplos de Configurações de Recursos de Rede.
Vários Tutoriais do Desenvolvedor relacionados estão disponíveis.
Configuração da VCN
A VCN na qual você deseja criar e implantar clusters deve ser configurada da seguinte forma:
- A VCN deve ter um bloco CIDR definido que seja grande o suficiente para todos os recursos exigidos por um cluster (ponto final da API do Kubernetes, nós de trabalho, pods, balanceadores de carga). Um bloco CIDR /16 seria grande o suficiente para quase todos os casos de uso (10.0.0.0/16, por exemplo). O bloco CIDR especificado para a VCN não deve se sobrepor ao bloco CIDR especificado para pods ao usar o plug-in CNI de flanela (consulte Usando o plug-in CNI de flanela para rede de pods) e para os serviços Kubernetes (consulte Blocos CIDR e o Serviço Kubernetes Engine (OKE)).
- A VCN deve ter um número apropriado de sub-redes definidas para nós de trabalho, balanceadores de carga, ponto final da API do Kubernetes e pods ao usar o plug-in CNI da Rede de Pods Nativa da VCN do OCI (consulte Usando o plug-in CNI da Rede de Pods Nativa da VCN do OCI para a rede de pods). A melhor prática é usar sub-redes regionais para simplificar a implementação do failover nos domínios de disponibilidade. Consulte Configuração da Sub-rede.
- A VCN deve ter regras de segurança definidas (em um ou ambos os grupos de segurança de rede e/ou listas de segurança para cada sub-rede). Consulte Configuração da Regra de Segurança em Grupos de Segurança de Rede e/ou Listas de Segurança.
- A Oracle recomenda que a Resolução de DNS seja selecionada para a VCN.
- Se você estiver usando sub-redes públicas, a VCN deverá ter um gateway de internet. Consulte Configuração do Gateway de Internet.
- Se você estiver usando sub-redes privadas, a VCN deverá ter um gateway NAT e um gateway de serviço. Consulte Configuração do Gateway NAT e Configuração do Gateway de Serviço.
- Se a VCN tiver um gateway NAT, de serviço ou de internet, ela deverá ter uma tabela de roteamento com as regras apropriadas definidas. Consulte Configuração da Tabela de Roteamento.
Consulte VCNs e Sub-redes e Exemplo de Configurações de Recursos de Rede.
Configuração do Gateway de Internet
Se você pretende usar sub-redes públicas (para nós de trabalho, balanceadores de carga e/ou para o ponto final da API do Kubernetes) e as sub-redes exigirem acesso de/para a internet, a VCN deverá ter um gateway de internet. O gateway de Internet deve ser especificado como alvo para o bloco CIDR de destino 0.0.0.0/0 como regra de roteamento em uma tabela de roteamento.
Consulte VCNs e Sub-redes e Exemplo de Configurações de Recursos de Rede.
Configuração do Gateway NAT
Se você pretende usar sub-redes privadas (para nós de trabalho, para o ponto final da API do Kubernetes ou para pods ao usar o plug-in CNI de Rede de Pod Nativa da VCN do OCI) e as sub-redes exigirem acesso à Internet, a VCN deverá ter um gateway NAT. Por exemplo, se você espera que os aplicativos implantados baixem software ou acessem serviços de terceiros.
O gateway NAT deve ser especificado como alvo para o bloco CIDR de destino 0.0.0.0/0 como regra de roteamento em uma tabela de roteamento.
ConsulteGateway NAT e Exemplo de Configurações de Recursos de Rede.
Configuração do Gateway de Serviço
Se você pretende usar sub-redes privadas para nós de trabalho, para o ponto final da API do Kubernetes ou para pods ao usar o plug-in CNI de Rede de Pod Nativa da VCN do OCI, a VCN deverá ter um gateway de serviço.
Crie o gateway de serviço na mesma VCN e no mesmo compartimento que a sub-rede dos nós de trabalho, a sub-rede do ponto final da API do Kubernetes ou a sub-rede dos pods e selecione a opção Todos os Serviços <region> no Oracle Services Network.
O gateway de serviço deve ser especificado como alvo para Todos os Serviços <region> no Oracle Services Network como regra de roteamento em uma tabela de roteamento.
Consulte Acesso aos Serviços Oracle: Gateway de Serviço e Exemplo de Configurações de Recursos de Rede.
Configuração da Tabela de Roteamento
Tabela de Roteamento para Sub-redes de Nós de Trabalho
Se você pretende implantar nós de trabalho em uma sub-rede pública, a tabela de roteamento de sub-rede deverá ter uma regra de roteamento que especifique o gateway de internet como alvo para o bloco CIDR de destino 0.0.0.0/0.
Se você pretende implantar nós de trabalho em uma sub-rede privada, a tabela de roteamento de sub-rede deverá ter:
- uma regra de roteamento que especifique o gateway de serviço como alvo para Todos os Serviços <region> no Oracle Services Network
- uma regra de roteamento que especifica o gateway NAT como alvo do bloco CIDR de destino 0.0.0.0/0
Tabela de Roteamento para Sub-redes de Ponto Final da API do Kubernetes
Se você pretende implantar o ponto final da API do Kubernetes em uma sub-rede pública, a tabela de roteamento de sub-rede deve ter uma regra de roteamento que especifique o gateway de internet como alvo do bloco CIDR de destino 0.0.0.0/0.
Se você pretende implantar o ponto final da API do Kubernetes em uma sub-rede privada, a tabela de roteamento de sub-rede deve ter:
- uma regra de roteamento que especifique o gateway de serviço como alvo para Todos os Serviços <region> no Oracle Services Network
- uma regra de roteamento que especifica o gateway NAT como alvo do bloco CIDR de destino 0.0.0.0/0
Tabela de Roteamento para Sub-redes de Balanceador de Carga
Se você pretende implantar balanceadores de carga em sub-redes públicas, a tabela de roteamento de sub-rede deve ter uma regra de roteamento que especifique o gateway de internet como alvo do bloco CIDR de destino 0.0.0.0/0.
Se você pretende implantar balanceadores de carga em sub-redes privadas, a tabela de roteamento de sub-rede pode ficar vazia.
Tabela de Roteamento para Sub-rede de Pods
Se você pretende usar o plug-in CNI da Rede de Pod Nativa da VCN do OCI para a rede de pod, implante pods em uma sub-rede privada. A tabela de roteamento de sub-rede deve ter:
- uma regra de roteamento que especifique o gateway de serviço como alvo para Todos os Serviços <region> no Oracle Services Network
- uma regra de roteamento que especifica o gateway NAT como alvo do bloco CIDR de destino 0.0.0.0/0
Se você pretende usar o plug-in CNI de flannel para rede de pod, não será necessária uma sub-rede de pod.
Observações sobre Configuração da Tabela de Roteamento
-
Para evitar a possibilidade de roteamento assimétrico, uma tabela de roteamento para uma sub-rede pública não pode conter uma regra de roteamento que atinja um gateway de internet e uma regra de roteamento que atinja um gateway de serviço (consulte Problemas com acesso às suas instâncias públicas dos serviços Oracle por meio de um gateway de serviço).
-
Para obter mais informações sobre a configuração de tabelas de roteamento, consulte:
Configuração das Opções de DHCP
A VCN na qual você deseja criar e implantar clusters deve ter Opções de DHCP configuradas. O valor padrão de Tipo de DNS do Resolvedor de Internet e VCN é aceitável.
Consulte Opções de DHCP e Exemplo de Configurações de Recursos de Rede.
Configuração da Sub-rede
As características do cluster que você deseja criar determinarão o número de sub-redes a serem configuradas. A melhor prática é usar sub-redes regionais para simplificar a implementação do failover nos domínios de disponibilidade.
A VCN na qual você deseja criar e implantar clusters deve ter pelo menos duas (opcionalmente, mais) subnets:
- uma sub-rede de ponto final da API do Kubernetes
- uma sub-rede de nós de trabalho
- uma regional ou duas sub-redes de balanceador de carga específicas do AD (opcional)
- uma sub-rede de pods (ao usar a rede de pods nativa da VCN)
- uma sub-rede bastion (opcional)
Você pode optar por combinar as sub-redes e também as regras de segurança. No entanto, essa abordagem torna a segurança mais difícil de gerenciar e, portanto, não é recomendada, a menos que você esteja usando grupos de segurança de rede para controlar o acesso a clusters.
Os blocos CIDR de sub-rede não devem se sobrepor aos blocos CIDR especificados para pods em execução no cluster (consulte Blocos CIDR e Kubernetes Engine (OKE)).
Os nós virtuais e os nós gerenciados têm requisitos diferentes; portanto, você precisa configurar sub-redes e sub-redes de pod do nó de trabalho de maneira ligeiramente diferente ao usar nós virtuais em vez de nós gerenciados.
As sub-redes devem ser configuradas com as seguintes propriedades:
- Tabela de Roteamento: consulte Configuração da Tabela de Roteamento
- Opções de DHCP: consulte Configuração de Opções de DHCP
- Grupos de Segurança de Rede e/ou Lista de Segurança: consulte Configuração da Regra de Segurança em Grupos de Segurança de Rede e/ou Listas de Segurança
Consulte VCNs e Sub-redes e Exemplo de Configurações de Recursos de Rede.
Configuração da Sub-rede de Ponto Final da API do Kubernetes
A sub-rede de ponto final da API Kubernetes hospeda um ponto final que fornece acesso à API do Kubernetes no plano de controle de cluster.
A sub-rede de ponto final da API do Kubernetes deve ser uma sub-rede regional e pode ser uma sub-rede privada ou pública:
- Se você especificar uma sub-rede pública para o ponto final da API do Kubernetes, poderá expor o ponto final à internet designando um endereço IP público ao ponto final. O endereço IP público permite que serviços de nuvem de terceiros (como SaaS CI/CD) acessem o ponto final da API do Kubernetes. Observe o seguinte:
- Se o ponto final da API do Kubernetes tiver um endereço IP público, deverão existir regras de roteamento e regras de segurança para permitir o acesso ao ponto final usando um gateway de internet (consulte Exemplo 1: Cluster com CNI de Flannel) Plug-in, Ponto Final Público de API do Kubernetes, Nós de Trabalho Privados e Balanceadores de Carga Públicos e Exemplo 3: Cluster com Plug-in OCI CNI, Ponto Final Público de API do Kubernetes, Nós de Trabalho Privados e Balanceadores de Carga Públicos).
- Se o ponto final da API do Kubernetes não tiver um endereço IP público, deverão existir regras de roteamento e regras de segurança para permitir o acesso ao ponto final usando um gateway de serviço e um gateway NAT (consulte Exemplo 2: Cluster com Plug-in CNI de Flannel, Ponto Final Privado de API do Kubernetes, Nós de Trabalho Privados e Balanceadores de Carga Públicos e Exemplo 4: Cluster com Plug-in OCI CNI, Ponto Final Privado de API do Kubernetes, Nós de Trabalho Privados e Balanceadores de Carga Públicos).
- Depois de criar um cluster, você poderá alterar subsequentemente se um endereço IP público foi designado ao ponto final da API do Kubernetes. Se você alterar se um endereço IP público foi designado ao ponto final, observe que também será necessário atualizar as regras de roteamento e as regras de segurança adequadamente.
- Se você especificar uma sub-rede privada para o ponto final da API do Kubernetes, o tráfego poderá acessar a sub-rede de ponto final da API do Kubernetes de outra sub-rede na VCN, de outra VCN ou da rede local (pareada com o FastConnect). Você também pode configurar um bastion host em uma sub-rede pública para acessar o ponto final da API do Kubernetes (consulte Configurando um Bastion para Acesso ao Cluster).
Configuração de Sub-rede de Nó de Trabalho
Uma sub-rede de nó de trabalho hospeda nós de trabalho. Todos os nós gerenciados em um pool de nós pertencem à mesma sub-rede do nó de trabalho.
A sub-rede de nó de trabalho pode ser uma única sub-rede regional ou várias sub-redes específicas do AD (uma em cada um dos domínios de disponibilidade).
Nós gerenciados/autogerenciados: a sub-rede de nó de trabalho pode ser uma sub-rede pública ou privada. No entanto, recomendamos que a sub-rede de nó de trabalho seja uma sub-rede privada para máxima segurança.
Nós virtuais: A sub-rede de nó de trabalho pode ser uma sub-rede pública ou privada. No entanto, recomendamos que a sub-rede de nó de trabalho seja uma sub-rede privada para máxima segurança. Também recomendamos que a sub-rede de nó de trabalho e a sub-rede de pod sejam a mesma (nesse caso, a sub-rede de nó de trabalho deve ser privada porque os nós virtuais exigem que a sub-rede de pod seja privada).
Configuração da Sub-rede do Pod
Uma sub-rede de pod hospeda os pods nos nós de trabalho em um pool de nós ao usar a rede de pods nativa da VCN (consulte Usando o plug-in CNI da Rede de Pods Nativa da VCN do OCI para a rede de pods).
A sub-rede de pod deve ser uma única sub-rede regional.
Nós gerenciados: A sub-rede de pod pode ser uma sub-rede pública ou privada. No entanto, recomendamos que a sub-rede de pod seja uma sub-rede privada para máxima segurança.
Nós virtuais: A sub-rede do pod deve ser uma sub-rede privada. Recomendamos que a sub-rede de pod e a sub-rede de nó de trabalho sejam a mesma sub-rede (nesse caso, a sub-rede de nó de trabalho também deve ser uma sub-rede privada).
Configuração de Sub-rede de Balanceador de Carga
A(s) sub-rede(s) de balanceador de carga conecta(am) os balanceadores de carga do Oracle Cloud Infrastructure criados pelos serviços do Kubernetes do tipo LoadBalancer.
As sub-redes de balanceador de carga podem ser redes regionais únicas ou sub-redes específicas do AD (uma em cada um dos domínios de disponibilidade). No entanto, recomendamos redes regionais.
As sub-redes de balanceador de carga podem ser públicas ou privadas, dependendo de como os aplicativos implantados no cluster serão acessados. Se os aplicativos forem acessados internamente na sua VCN, use sub-redes privadas para as sub-redes de balanceador de carga. Se os aplicativos forem acessados pela Internet, use sub-redes públicas para as sub-redes de balanceador de carga.
Configuração da Sub-rede do Bastion (Opcional)
Um bastion opcional em uma sub-rede bastion pode fornecer acesso seguro ao ponto final da API do Kubernetes e acesso SSH aos nós de trabalho. Consulte Configurando um Bastion para Acesso ao Cluster.
Configuração da Regra de Segurança em Grupos de Segurança de Rede e/ou Listas de Segurança
A VCN na qual você deseja criar e implantar clusters deve ter regras de segurança definidas. É possível definir as regras de segurança de uma ou de ambas as formas a seguir:
- Em Grupos de segurança de rede (recomendado) que você seleciona para pools de nós, para o ponto final da API do Kubernetes, para pods (ao usar a rede de pods nativa da VCN) e para balanceadores de carga (se especificados) ao criar um cluster.
- Em Listas de segurança que já estão associadas às sub-redes selecionadas para os nós de trabalho, para o ponto final da API do Kubernetes, para pods (ao usar a rede de pods nativa da VCN) e para balanceadores de carga (se especificados) ao criar um cluster.
Os nós de trabalho, o ponto final da API do Kubernetes, os pods (ao usar a rede de pod nativa da VCN) e o balanceador de carga têm diferentes requisitos de regra de segurança, conforme descrito neste tópico. Você pode adicionar mais regras para atender às suas necessidades específicas.
Se você especificar regras de segurança nos grupos de segurança de rede e nas listas de segurança, todas as regras de segurança serão aplicadas (ou seja, a união das regras de segurança).
Para obter mais informações, consulte:
- Exemplo de Configurações de Recursos de Rede
- Listas de Segurança
- Grupos de Segurança de Rede
- Regras de Segurança
Regras de Segurança para o Ponto Final da API do Kubernetes
As seguintes regras de entrada devem ser definidas para o ponto final da API do Kubernetes, em um grupo de segurança de rede (recomendado) e/ou em uma lista de segurança:
| Estado | Origem | Protocolo/Dest. - Porta | Descrição |
|---|---|---|---|
| Com monitoramento de estado | CIDR dos Nós de Trabalho | TCP/6443 | Colaborador do Kubernetes para comunicação do ponto final da API do Kubernetes. |
| Com monitoramento de estado | CIDR dos Nós de Trabalho | TCP/12250 | Colaborador do Kubernetes para comunicação do ponto final da API do Kubernetes. |
| Com monitoramento de estado | Pods CIDR | TCP/6443 | Comunicação de ponto final da API do Pod para o Kubernetes (ao usar a rede de pod nativa da VCN). |
| Com monitoramento de estado | Pods CIDR | TCP/12250 | Comunicação de ponto final da API do Pod para o Kubernetes (ao usar a rede de pod nativa da VCN). |
| Com monitoramento de estado | CIDR dos Nós de Trabalho | ICMP 3,4 | Descoberta de Caminho. |
As seguintes regras de entrada opcionais podem ser definidas para o ponto final da API do Kubernetes, em um grupo de segurança de rede (recomendado) e/ou em uma lista de segurança:
| Estado | Origem | Protocolo/Dest. Porta | Descrição |
|---|---|---|---|
| Com monitoramento de estado | 0.0.0.0/0 ou sub-redes específicas | TCP/6443 | Acesso do cliente ao ponto final da API do Kubernetes |
As seguintes regras de saída devem ser definidas para o ponto final da API do Kubernetes, em um grupo de segurança de rede (recomendado) e/ou em uma lista de segurança:
| Estado | Destino | Protocolo/Dest. Porta | Descrição |
|---|---|---|---|
| Com monitoramento de estado | Todos os Serviços <region> no Oracle Services Network | TCP/443 | Permitir que o ponto final da API do Kubernetes se comunique com o OKE. |
| Com monitoramento de estado | CIDR dos Nós de Trabalho | TCP/ALL | Todo o tráfego para nós de trabalho (ao usar flannel para rede de pods). |
| Com monitoramento de estado | Pods CIDR | ALL/ALL |
Ponto final da API do Kubernetes para comunicação de pod (ao usar a rede de pod nativa da VCN). |
| Com monitoramento de estado | CIDR dos Nós de Trabalho | ICMP 3,4 | Descoberta de Caminho. |
| Com monitoramento de estado | CIDR dos Nós de Trabalho | TCP 10250, ICMP | Ponto final da API do Kubernetes para comunicação do nó de trabalho (ao usar a rede de pod nativa da VCN). |
Regras de Segurança para Nós de Trabalho
Os nós de trabalho são criados com endereços IP públicos ou privados, de acordo com a especificação de sub-redes públicas ou privadas ao definir os pools de nós em um cluster. O Kubernetes Engine deve ser capaz de acessar nós de trabalho.
As seguintes regras de entrada devem ser definidas para nós de trabalho, em um grupo de segurança de rede (recomendado) e/ou em uma lista de segurança:
| Estado | Origem | Protocolo/Dest. Porta | Descrição |
|---|---|---|---|
| Com monitoramento de estado | CIDR dos Nós de Trabalho | ALL/ALL | Permite comunicação de (ou para) nós de trabalho. |
| Com monitoramento de estado | Pods CIDR | ALL/ALL | Permita que pods em um nó de trabalho se comuniquem com pods em outros nós de trabalho (ao usar a rede de pods nativa da VCN). |
| Com monitoramento de estado | CIDR de Ponto Final da API Kubernetes | TCP/ALL | Permitir que o ponto final da API do Kubernetes se comunique com nós de trabalho. |
| Com monitoramento de estado | 0.0.0.0/0 | ICMP 3,4 | Descoberta de Caminho. |
| Com monitoramento de estado | CIDR de Ponto Final da API Kubernetes | TCP 10250, ICMP | Ponto final da API do Kubernetes para comunicação do nó de trabalho (ao usar a rede de pod nativa da VCN). |
As seguintes regras de entrada opcionais podem ser definidas para nós de trabalho (somente nós gerenciados), em um grupo de segurança de rede (recomendado) e/ou em uma lista de segurança:
| Estado | Origem | Protocolo/Dest. Porta | Descrição |
|---|---|---|---|
| Com monitoramento de estado | 0.0.0.0/0 ou CIDR de sub-rede | TCP/22 | (opcional) Permita tráfego SSH de entrada para nós de trabalho. |
As seguintes regras de saída devem ser definidas para nós de trabalho, em um grupo de segurança de rede (recomendado) e/ou em uma lista de segurança:
| Estado | Destino | Protocolo/Dest. Porta | Descrição |
|---|---|---|---|
| Com monitoramento de estado | CIDR dos Nós de Trabalho | ALL/ALL | Permite comunicação de (ou para) nós de trabalho. |
| Com monitoramento de estado | Pods CIDR | ALL/ALL | Permita que os nós de trabalho se comuniquem com pods em outros nós de trabalho (ao usar a rede de pods nativa da VCN). |
| Com monitoramento de estado | 0.0.0.0/0 | ICMP 3,4 | Descoberta de Caminho. |
| Com monitoramento de estado | Todos os Serviços <region> no Oracle Services Network | TCP/ALL | Permita que os nós se comuniquem com o OKE. |
| Com monitoramento de estado | CIDR de Ponto Final da API Kubernetes | TCP/6443 | Colaborador do Kubernetes para comunicação do ponto final da API do Kubernetes. |
| Com monitoramento de estado | CIDR de Ponto Final da API Kubernetes | TCP/12250 | Colaborador do Kubernetes para comunicação do ponto final da API do Kubernetes. |
As seguintes regras de saída opcionais podem ser definidas para nós de trabalho, em um grupo de segurança de rede (recomendado) e/ou em uma lista de segurança:
| Estado | Destino | Protocolo/Dest. Porta | Descrição |
|---|---|---|---|
| Com monitoramento de estado | 0.0.0.0/0 | TCP/ALL | (opcional) Permita que os nós de trabalho se comuniquem com a internet. |
Regras de Segurança para Sub-redes de Pod
Ao usar o plug-in CNI de Rede do Pod Nativo da VCN do OCI para a rede do pod:
-
as regras de segurança definidas para a sub-rede do nó de trabalho, em um grupo de segurança de rede (recomendado) e/ou em uma lista de segurança, devem incluir:
- Regras de entrada e saída com monitoramento de estado que permitem todo o tráfego entre nós de trabalho
- Regras de entrada e saída com monitoramento de estado que permitem todo o tráfego entre nós de trabalho e balanceador de carga
- Regras de saída com monitoramento de estado que permitam tráfego entre nós de trabalho e o Kubernetes Engine
- as regras de segurança definidas para a sub-rede do pod, em um grupo de segurança de rede (recomendado) e/ou em uma lista de segurança, devem incluir regras de entrada e saída com monitoramento de estado que permitam todo o tráfego entre pods
As seguintes regras de entrada devem ser definidas para sub-redes de pod, em um grupo de segurança de rede (recomendado) e/ou em uma lista de segurança:
| Estado | Origem | Protocolo/Dest. Porta | Descrição |
|---|---|---|---|
| Com monitoramento de estado | CIDR de Ponto Final da API Kubernetes | ALL/ALL | Ponto final da API do Kubernetes para comunicação de pod (ao usar a rede de pod nativa da VCN). |
| Com monitoramento de estado | CIDR dos Nós de Trabalho | ALL/ALL | Permita que pods em um nó de trabalho se comuniquem com pods em outros nós de trabalho. |
| Com monitoramento de estado | Pods CIDR | ALL/ALL | Permita que os pods se comuniquem entre si. |
As seguintes regras de saída devem ser definidas para sub-redes de pod, em um grupo de segurança de rede (recomendado) e/ou em uma lista de segurança:
| Estado | Destino | Protocolo/Dest. Porta | Descrição |
|---|---|---|---|
| Com monitoramento de estado | Pods CIDR | ALL/ALL | Permita que os pods se comuniquem entre si. |
| Com monitoramento de estado | Todos os Serviços <region> no Oracle Services Network | ICMP 3,4 | Descoberta de Caminho. |
| Com monitoramento de estado | Todos os Serviços <region> no Oracle Services Network | TCP/ALL | Permita que os nós de trabalho se comuniquem com os serviços do OCI. |
| Com monitoramento de estado | CIDR de Ponto Final da API Kubernetes | TCP/6443 | Comunicação de ponto final da API do Pod para o Kubernetes (ao usar a rede de pod nativa da VCN). |
| Com monitoramento de estado | CIDR de Ponto Final da API Kubernetes | TCP/12250 | Comunicação de ponto final da API do Pod para o Kubernetes (ao usar a rede de pod nativa da VCN). |
As seguintes regras de saída opcionais podem ser definidas para uma sub-rede de pod, em um grupo de segurança de rede (recomendado) e/ou em uma lista de segurança:
| Estado | Destino | Protocolo/Dest. Porta | Descrição |
|---|---|---|---|
| Com monitoramento de estado | 0.0.0.0/0 | TCP/443 | (opcional) Permitir que os pods se comuniquem com a Internet. |
Regras de Segurança para Balanceadores de Carga e Balanceadores de Carga da Rede
Quando o Kubernetes Engine provisiona um balanceador de carga do OCI ou balanceador de carga de rede para um serviço Kubernetes do tipo LoadBalancer, devem existir regras de segurança apropriadas para permitir tráfego de entrada e saída de/para a sub-rede do balanceador de carga ou do balanceador de carga de rede. No caso de nós gerenciados (não nós virtuais), essas regras de segurança são criadas automaticamente por padrão para balanceadores de carga, mas não são criadas automaticamente por padrão para balanceadores de carga de rede. Para obter mais informações sobre o provisionamento de um balanceador de carga do OCI ou balanceador de carga de rede para um serviço Kubernetes do tipo LoadBalancer, consulte Definindo Serviços do Kubernetes do Tipo LoadBalancer.
Você pode definir regras de segurança de entrada e saída para a sub-rede em um grupo de segurança de rede (recomendado) e/ou em uma lista de segurança. Para obter mais informações, consulte:
- Especificando Grupos de Segurança de Rede (recomendado)
- Especificando Opções de Gerenciamento da Lista de Segurança ao Provisionar um Balanceador de Carga do OCI
- Especificando Opções de Gerenciamento da Lista de Segurança ao Provisionar um Balanceador de Carga de Rede do OCI
Defina a seguinte regra de segurança de entrada em uma ou em ambas:
- um grupo de segurança de rede (recomendado) ao qual o recurso do balanceador de carga ou do balanceador de carga de rede foi adicionado
- uma lista de segurança associada à sub-rede do balanceador de carga ou do balanceador de carga de rede
| Estado | Origem | Protocolo/Dest. Porta | Descrição |
|---|---|---|---|
| Com monitoramento de estado | 0.0.0.0/0 ou CIDR específico | TCP/443 | Permitir tráfego de entrada para o Balanceador de Carga. |
Defina o Protocolo e a Porta de Destino da regra de entrada adequadamente para requisitos específicos do aplicativo. Por exemplo, especifique UDP como o protocolo para um aplicativo que lida com o tráfego UDP.
Defina a seguinte regra de segurança de saída em uma ou ambas:
- um grupo de segurança de rede (recomendado) ao qual o recurso do balanceador de carga ou do balanceador de carga de rede foi adicionado
- uma lista de segurança associada à sub-rede do balanceador de carga ou do balanceador de carga de rede
| Estado | Destino | Protocolo/Dest. Porta | Descrição |
|---|---|---|---|
| Com monitoramento de estado | CIDR dos nós de trabalho | TODOS/30000-32767 | Permita tráfego para nós de trabalho. |
Por padrão, os balanceadores de carga do OCI ou os balanceadores de carga de rede provisionados pelas solicitações de proxy do Kubernetes Engine para todos os nós de trabalho no cluster. Quando as solicitações são submetidas a proxy para nós de trabalho no cluster, as seguintes regras de segurança de entrada e saída devem existir (em um grupo de segurança de rede (recomendado) e/ou em uma lista de segurança) para que o balanceador de carga ou o balanceador de carga de rede se comunique com os nós de trabalho na porta 10256 (a porta de integridade do kube-proxy):
- Regra de segurança de entrada para a lista de segurança da sub-rede do nó de trabalho (ou grupo de segurança de rede) para permitir que o balanceador de carga ou o balanceador de carga de rede se comunique com o kube-proxy nos nós de trabalho:
Estado Origem Protocolo/Dest. Porta Descrição Com monitoramento de estado CIDR da sub-rede do balanceador de carga ou da rede TODOS/10256 Permita que o balanceador de carga ou o balanceador de carga de rede do OCI se comunique com o kube-proxy nos nós de trabalho. - Regra de segurança de saída para a lista de segurança (ou grupo de segurança de rede) do balanceador de carga ou da sub-rede do balanceador de carga para permitir que o balanceador de carga ou o balanceador de carga de rede se comunique com o kube-proxy nos nós de trabalho:
Estado Destino Protocolo/Dest. Porta Descrição Com monitoramento de estado CIDR da sub-rede do nó de trabalho TODOS/10256 Permita que o balanceador de carga ou o balanceador de carga de rede do OCI se comunique com o kube-proxy nos nós de trabalho.
Ao provisionar um balanceador de carga de rede para um serviço do Kubernetes do tipo LoadBalancer:
- Você pode especificar que as solicitações terminem no endereço IP do cliente especificado nos cabeçalhos de pacotes IP, em vez de serem submetidas a proxy para outros nós de trabalho no cluster (definindo
externalTrafficPolicy: Local). Consulte Encerrando Solicitações no Nó de Recebimento. - Se você especificar que as solicitações terminam no endereço IP do cliente, também poderá especificar se deseja preservar o endereço IP do cliente nos cabeçalhos de pacotes IP (usando a anotação
oci-network-load-balancer.oraclecloud.com/is-preserve-source). Consulte Preservando o Endereço IP do Cliente.
Observe que, em ambos os casos, você deve ter configurado uma regra de segurança (em um grupo de segurança de rede (recomendado) e/ou em uma lista de segurança) para os nós de trabalho no cluster para permitir o tráfego de entrada do bloco CIDR em que as conexões do cliente são feitas, para todas as portas de nó (30000 a 32767). Se o aplicativo for exposto à Internet, defina o bloco CIDR de Origem da regra de segurança como 0.0.0.0/0. Como alternativa, defina o bloco CIDR de Origem da regra de segurança para um bloco CIDR específico (por exemplo, se as conexões do cliente vierem de uma sub-rede específica).
| Estado | Origem | Protocolo/Dest. Porta | Descrição |
|---|---|---|---|
| Com monitoramento de estado | 0.0.0.0/0 ou CIDR de sub-rede | TODOS/30000-32767 | Permita que os nós de trabalho recebam conexões por meio do OCI Network Load Balancer. |
Regras de Segurança para Sub-redes do Bastion
Um bastion opcional em uma sub-rede bastion pode fornecer acesso seguro ao ponto final da API do Kubernetes e acesso SSH aos nós de trabalho. Para obter informações sobre as regras de segurança de entrada e saída a serem definidas, consulte Configurando um Bastion para Acesso ao Cluster.