Pré-requisitos para implantar o Controlador de Entrada Nativo do OCI como um Complemento de Cluster
Descubra o que você precisa fazer para poder implantar o controlador de entrada nativo do OCI como um complemento de cluster para balancear a carga e rotear o tráfego de entrada para pods de serviço executados em nós de trabalho em um cluster do Kubernetes.
Antes de implantar o controlador de entrada nativo do OCI como um complemento de cluster:
- Crie um novo cluster ou identifique um cluster existente que tenha rede de pod nativo da VCN ou Sobreposição de canal como o tipo de rede. O cluster pode ser um cluster aprimorado ou um cluster básico. O cluster deve estar executando o Kubernetes versão 1.28 ou posterior. Consulte Criando um Cluster.
- Configure regras de segurança do balanceador de carga para permitir tráfego de entrada e saída de/para a sub-rede do balanceador de carga. Consulte Configuração de Sub-rede do Balanceador de Carga.
- Configure um controlador de instâncias, um controlador de usuários ou um controlador de identidades de carga de trabalho para permitir que o controlador de entrada nativo do OCI acesse outros serviços e recursos do Oracle Cloud Infrastructure. Consulte Configurando um Controlador de Instâncias, um Controlador de Usuários ou um Controlador de Identidades de Carga de Trabalho para Ativar o Acesso aos Serviços e Recursos do OCI.
- Conceda permissões ao controlador de instâncias, ao controlador de usuários ou ao controlador de identidades de carga de trabalho para permitir que o controlador de entrada nativo do OCI acesse recursos. Consulte Concedendo Permissões ao Complemento do Cluster do Controlador de Entrada Nativo do OCI.
- Instale o cert-manager para gerar e gerenciar os certificados TLS exigidos pelo servidor webhook que suporta o recurso de portas de preparação do pod. Consulte Instalando o cert-manager.
Configurando um Controlador de Instâncias, Controlador de Usuários ou Controlador de Identidades de Carga de Trabalho para Ativar o Acesso a Serviços e Recursos do OCI
Para criar um balanceador de carga e rotear o tráfego de entrada, o controlador de entrada nativo do OCI, instalado como um programa independente ou como complemento de cluster, executa ações em outros recursos do serviço Oracle Cloud Infrastructure (incluindo o serviço Load Balancer e o serviço Certificates). Para executar essas ações nos recursos de serviço do OCI, o pod do controlador de entrada nativo do OCI usa as credenciais de um ator autorizado (ou principal). No momento, você pode configurar os seguintes tipos de principal para permitir que o controlador de entrada nativo do OCI execute ações nos recursos de serviço do OCI:
- Controlador de instâncias: O controlador de entrada nativo do OCI usa a identidade da instância na qual ele está sendo executado. Consulte Usando controladores de instância para permitir o acesso a serviços e recursos do OCI.
- Controlador de usuários: O controlador de entrada nativo do OCI usa a identidade de um usuário do OCI. Consulte Usando controladores de usuário para permitir o acesso a serviços e recursos do OCI.
- Controlador de identidades de carga de trabalho: O controlador de entrada nativo do OCI usa a identidade de um recurso de carga de trabalho em execução em um cluster do Kubernetes. Consulte Usando controladores de identidade de carga de trabalho para permitir o acesso a serviços e recursos do OCI.
Observação:
- O uso de controladores de instância para permitir que o controlador de entrada nativo do OCI acesse serviços e recursos do OCI não é suportado em clusters com nós virtuais.
- O uso de controladores de identidade de carga de trabalho para permitir que o controlador de entrada nativo do OCI acesse serviços e recursos do OCI é suportado com clusters aprimorados, mas não com clusters básicos.
Usando controladores de instância para permitir o acesso a serviços e recursos do OCI
Você pode configurar um controlador de instâncias para permitir que o controlador de entrada nativo do OCI execute ações nos recursos do serviço OCI. Observe que você só pode usar controladores de instância com nós gerenciados.
Para configurar um controlador de instâncias:
- Crie um novo grupo dinâmico para conter as instâncias de computação que hospedam os nós de trabalho do cluster:
- Abra o menu de navegação e clique em Identidade e Segurança. Em Identidade, clique em Domínios. Em domínio de identidades, clique em Grupos dinâmicos.
-
Selecione o compartimento ao qual as instâncias de computação pertencem.
-
Siga as instruções em Para criar um grupo dinâmico e dê um nome ao grupo dinâmico (por exemplo,
acme-oke-native-ingress-controller-dyn-grp
). - Digite uma regra que inclua as instâncias de computação no compartimento, no formato:
ALL {instance.compartment.id = '<compartment-ocid>'}
em que
<compartment-ocid>
é o OCID do compartimento no qual os pools de nós do cluster são criados.Por exemplo:
ALL {instance.compartment.id = 'ocid1.compartment.oc1..aaaaaaaa23______smwa'}
- Clique em Criar Grupo Dinâmico.
Antes de implantar o controlador de entrada nativo do OCI, você:
-
Conceda permissões à instância na qual o controlador de entrada nativo do OCI está sendo executado por meio do grupo dinâmico. Consulte Concedendo Permissões ao Complemento do Cluster do Controlador de Entrada Nativo do OCI.
-
Indique que você deseja usar controladores de instância com o add-on do controlador de entrada nativo do OCI definindo o argumento de configuração
authType
comoinstance
. Por exemplo:{ "key": "authType", "value": "instance" }
Consulte Implantando o Complemento do Controlador de Entrada Nativo do OCI
Usando controladores de usuário para permitir o acesso a serviços e recursos do OCI
Você pode configurar um controlador de usuários para permitir que o controlador de entrada nativo do OCI execute ações nos recursos do serviço OCI.
Para configurar um principal do usuário:
- Se um usuário adequado ainda não existir, crie um usuário no serviço IAM (consulte Para criar um usuário).
- Se ainda não existir um grupo adequado, crie um grupo no serviço IAM (consulte Para criar um grupo).
- Adicione o usuário ao grupo (consulte Para adicionar um usuário a um grupo).
-
Obtenha estes itens:
- Par de chaves RSA no formato PEM (no mínimo 2048 bits). Consulte Como Gerar uma Chave de Assinatura de API.
- Impressão digital da chave pública. Consulte Como Obter a Impressão Digital da Chave.
- OCID da Tenancy e OCID do usuário. Consulte Onde Obter o OCID da Tenancy e o OCID do Usuário.
- Faça o upload da chave pública do par de chaves na Console. Consulte Como Fazer o Upload da Chave Pública.
- Crie um arquivo de configuração como um arquivo .yaml contendo informações de credencial, no seguinte formato:
auth: region: <region-identifier> passphrase: <passphrase> user: <user-ocid> fingerprint: <fingerprint> tenancy: <tenancy-ocid>
em que:region: <region-identifier>
é a região em que reside o cluster. Por exemplo,us-ashburn-1
passphrase: <passphrase>
especifica a frase-senha usada para a chave se ela estiver criptografada.user: <user-ocid>
é o OCID do usuário que o controlador de entrada nativo do OCI deverá usar.fingerprint: <fingerprint>
é a impressão digital da chave pública.tenancy: <tenancy-ocid>
é o OCID da tenancy que contém o cluster.
Por exemplo:
auth: region: us-ashburn-1 passphrase: examplepass user: ocid1.user.oc1..aaaaaaaa_example fingerprint: 67:d9:74:4b:21:example tenancy: ocid1.tenancy.oc1..aaaaaaaa_example
- Crie um recurso secreto do Kubernetes no cluster digitando:
kubectl create secret generic <secret-name> \ --from-file=config=<config-file>.yaml \ --from-file=private-key=<private-key-file-path>.pem \ --namespace <namespace>
em que:<secret-name>
especifica o nome do segredo a ser criado. Por exemplo,oci-config
--from-file=config=<config-file>.yaml
especifica o nome e o caminho do arquivo .yaml que contém as informações de credencial criadas anteriormente. Por exemplo,user-auth-config.yaml
--from-file=private-key=./oci/oci_api_key.pem
especifica o nome e o caminho do arquivo de chave privada submetido a download. Por exemplo,./oci/oci_api_key.pem
--namespace <namespace>
especifica o namespace que contém o controlador de entrada nativo do OCI
Por exemplo:
kubectl create secret generic oci-config \ --from-file=config=user-auth-config.yaml \ --from-file=private-key=./oci/oci_api_key.pem \ --namespace acme-namespace
Antes de implantar o controlador de entrada nativo do OCI, você:
- Conceda permissões ao usuário por meio do grupo ao qual o usuário pertence. Consulte Concedendo Permissões ao Complemento de Cluster do Controlador de Entrada Nativo do OCI.
-
Indique que você deseja usar controladores de usuário com o add-on do controlador de entrada nativo do OCI definindo os seguintes argumentos de configuração:
- definir
authType
comouser
- definir
authSecretName
como o nome do segredo do Kubernetes criado anteriormente
Por exemplo:
{ "key": "authType", "value": "user" }, { "key": "authSecretName", "value": "oci-config" }
Consulte Implantando o Complemento do Controlador de Entrada Nativo do OCI
- definir
Usando controladores de identidade de carga de trabalho para permitir o acesso a serviços e recursos do OCI
Você pode configurar um controlador de identidade de carga de trabalho para permitir que o controlador de entrada nativo do OCI execute ações nos recursos do serviço OCI. Observe que você só pode usar controladores de identidade de carga de trabalho com clusters aprimorados.
Para configurar um controlador de identidades de carga de trabalho:
- Obtenha o OCID do cluster (por exemplo, usando a guia Detalhes do Cluster na Console).
Antes de implantar o controlador de entrada nativo do OCI, você:
- Conceda permissões à identidade da carga de trabalho do controlador de entrada nativo do OCI. Consulte Concedendo Permissões ao Complemento do Cluster do Controlador de Entrada Nativo do OCI.
- Indique que você deseja usar principais de identidade de carga de trabalho com o add-on do controlador de entrada nativo do OCI definindo o argumento de configuração
authType
comoworkloadIdentity
. Por exemplo:{ "key": "authType", "value": "workloadIdentity" }
Consulte Implantando o Complemento do Controlador de Entrada Nativo do OCI
Concedendo Permissões ao Complemento de Cluster do Controlador de Entrada Nativo do OCI
O controlador de entrada nativo do OCI requer permissões para acessar recursos criados por outros serviços do Oracle Cloud Infrastructure (como o serviço Load Balancer e o serviço Certificates). As permissões concedidas são as mesmas, independentemente de você instalar o controlador de entrada nativo do OCI como um programa independente ou como um complemento de cluster. E as permissões são as mesmas, independentemente de você ter configurado um controlador de instâncias, um controlador de usuários ou um controlador de identidades de carga de trabalho para o controlador de entrada nativo do OCI. No entanto, a forma como você concede essas permissões depende do tipo de principal que você configurou:
- Ao usar controladores de instância, o controlador de entrada nativo do OCI herda as permissões concedidas à instância na qual ele está sendo executado por meio de um grupo dinâmico ao qual a instância pertence. Para obter informações sobre como criar o grupo dinâmico para controladores de instância, consulte Usando controladores de instância para permitir o acesso a serviços e recursos do OCI.
- Ao usar controladores de usuário, o controlador de entrada nativo do OCI herda as permissões concedidas a um usuário por meio de um grupo ao qual o usuário pertence. Para obter informações sobre como criar o usuário e o grupo para controladores de usuário, consulte Usando controladores de usuário para permitir o acesso a serviços e recursos do OCI.
- Ao usar controladores de identidade de carga de trabalho, o controlador de entrada nativo do OCI herda as permissões concedidas a uma carga de trabalho em execução em um cluster especificado, na conta de serviço do Kubernetes e no namespace criados para o controlador de entrada nativo do OCI durante a instalação. Para obter mais informações, consulte Usando controladores de identidade de carga de trabalho para permitir o acesso a serviços e recursos do OCI.
Para configurar permissões para o controlador de entrada nativo do OCI, crie uma política para o grupo (no caso de controladores de usuário), para o grupo dinâmico (no caso de controladores de instância) ou para a carga de trabalho (no caso de controladores de identidade de carga de trabalho), com instruções de política para acessar serviços e recursos do OCI:
- Abra o menu de navegação e clique em Identidade e Segurança. Em Identidade, clique em Políticas.
- Siga as instruções em Para criar uma política e dê um nome à política (por exemplo,
acme-oke-native-ingress-controller-policy
). -
Se você estiver usando controladores de instância ou controladores de usuário, informe instruções de política para permitir o acesso aos serviços e recursos do OCI usados pelo controlador de entrada nativo do OCI, no formato:
Allow <group|dynamic-group> <subject-name> to <verb> <resource> in <location>
em que:
<group|dynamic-group>
égroup
(no caso de controladores de usuário) oudynamic-group
(no caso de controladores de instância)<subject-name>
é o nome do grupo (no caso de controladores de usuário) ou o nome do grupo dinâmico (no caso de controladores de instância). Por exemplo,acme-oke-nat-ing-cont-dyn-grp
. Observe que, se um grupo ou grupo dinâmico não estiver no domínio de identidades padrão, coloque o nome do grupo ou grupo dinâmico no formato<group|dynamic-group> '<identity-domain-name>'/'<group-name|dynamic-group-name>'
como prefixo. Você também pode especificar um grupo ou grupo dinâmico usando seu OCID, no formatogroup id <group-ocid>
oudynamic-group id <dynamic-group-ocid>
.<verb> <resource>
é um dos seguintes (todos eles são necessários, em instruções de política separadas):manage load-balancers
use virtual-network-family
manage cabundles
manage cabundle-associations
manage leaf-certificates
read leaf-certificate-bundles
manage certificate-associations
read certificate-authorities
manage certificate-authority-associations
read certificate-authority-bundles
read public-ips
manage floating-ips
manage waf-family
read cluster-family
<location>
é um destes:tenancy
, se você quiser que o controlador de entrada nativo do OCI tenha acesso a recursos em toda a tenancy.compartment <compartment-name>
se você quiser que apenas o controlador de entrada nativo do OCI tenha acesso a recursos no compartimento com o nome especificado comocompartment <compartment-name>
.
Por exemplo:
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage load-balancers in compartment acme-oke-cluster-compartment
A sintaxe da lista completa de instruções de política é a seguinte:
Allow <group|dynamic-group> <subject-name> to manage load-balancers in <location> Allow <group|dynamic-group> <subject-name> to use virtual-network-family in <location> Allow <group|dynamic-group> <subject-name> to manage cabundles in <location> Allow <group|dynamic-group> <subject-name> to manage cabundle-associations in <location> Allow <group|dynamic-group> <subject-name> to manage leaf-certificates in <location> Allow <group|dynamic-group> <subject-name> to read leaf-certificate-bundles in <location> Allow <group|dynamic-group> <subject-name> to manage certificate-associations in <location> Allow <group|dynamic-group> <subject-name> to read certificate-authorities in <location> Allow <group|dynamic-group> <subject-name> to manage certificate-authority-associations in <location> Allow <group|dynamic-group> <subject-name> to read certificate-authority-bundles in <location> Allow <group|dynamic-group> <subject-name> to read public-ips in <location> Allow <group|dynamic-group> <subject-name> to manage floating-ips in <location> Allow <group|dynamic-group> <subject-name> to manage waf-family in <location> Allow <group|dynamic-group> <subject-name> to read cluster-family in <location>
Exemplo da lista completa de instruções de política:
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage load-balancers in compartment acme-oke-cluster-compartment Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to use virtual-network-family in compartment acme-oke-cluster-compartment Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage cabundles in compartment acme-oke-cluster-compartment Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage cabundle-associations in compartment acme-oke-cluster-compartment Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage leaf-certificates in compartment acme-oke-cluster-compartment Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read leaf-certificate-bundles in compartment acme-oke-cluster-compartment Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage certificate-associations in compartment acme-oke-cluster-compartment Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read certificate-authorities in compartment acme-oke-cluster-compartment Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage certificate-authority-associations in compartment acme-oke-cluster-compartment Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read certificate-authority-bundles in compartment acme-oke-cluster-compartment Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read public-ips in compartment acme-oke-cluster-compartment Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage floating-ips in compartment acme-oke-cluster-compartment Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage waf-family in compartment acme-oke-cluster-compartment Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read cluster-family in compartment acme-oke-cluster-compartment
- Se você estiver usando controladores de identidade de carga de trabalho, digite instruções de política para permitir o acesso aos serviços e recursos do OCI usados pelo controlador de entrada nativo do OCI, no formato:
Allow any-user to <verb> <resource> in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
em que:
<verb> <resource>
é um dos seguintes (todos eles são necessários, em instruções de política separadas):manage load-balancers
use virtual-network-family
manage cabundles
manage cabundle-associations
manage leaf-certificates
read leaf-certificate-bundles
manage certificate-associations
read certificate-authorities
manage certificate-authority-associations
read certificate-authority-bundles
read public-ips
manage floating-ips
manage waf-family
read cluster-family
<location>
é um destes:tenancy
, se você quiser que o controlador de entrada nativo do OCI tenha acesso a recursos em toda a tenancy.compartment <compartment-name>
se você quiser que apenas o controlador de entrada nativo do OCI tenha acesso a recursos no compartimento com o nome especificado comocompartment <compartment-name>
.
request.principal.namespace = 'native-ingress-controller-system'
é o nome do namespace criado para o controlador de entrada nativo do OCI durante a instalação.request.principal.service_account = 'oci-native-ingress-controller'
é o nome da conta de serviço criada para o controlador de entrada nativo do OCI durante a instalação.<cluster-ocid>
é o OCID do cluster obtido anteriormente.
Por exemplo:
Allow any-user to manage load-balancers in tenancy where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa______ska'}
A sintaxe da lista completa de instruções de política é:
Allow any-user to manage load-balancers in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'} Allow any-user to use virtual-network-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'} Allow any-user to manage cabundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'} Allow any-user to manage cabundle-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'} Allow any-user to manage leaf-certificates in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'} Allow any-user to read leaf-certificate-bundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'} Allow any-user to manage certificate-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'} Allow any-user to read certificate-authorities in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'} Allow any-user to manage certificate-authority-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'} Allow any-user to read certificate-authority-bundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'} Allow any-user to read public-ips in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'} Allow any-user to manage floating-ips in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'} Allow any-user to manage waf-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'} Allow any-user to read cluster-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Instalando o cert-manager
O controlador de entrada nativo da OCI, instalado como um programa independente ou como complemento de cluster, usa webhooks para injetar portas de prontidão de pod em especificações de pod. Para garantir a segurança, o servidor webhook precisa ser executado no modo HTTPS, o que requer um par de certificados e chaves. O controlador de entrada nativo do OCI usa o Certificate Manager (também conhecido como cert-manager) para gerar e gerenciar os certificados e as chaves do servidor webhook; portanto, você precisa instalar o cert-manager no cluster para usar portas de prontidão de pod.
Independentemente de você instalar o controlador de entrada nativo do OCI como um programa independente ou como um complemento de cluster, poderá instalar e executar o gerenciador de certificados de duas maneiras:
-
Você pode instalar e executar o cert-manager como um produto de código aberto, digitando:
kubectl apply -f https://github.com/jetstack/cert-manager/releases/latest/download/cert-manager.yaml
-
Você pode instalar e executar o cert-manager como um complemento de cluster. Para obter mais informações sobre como instalar o cert-manager como um complemento de cluster, consulte Instalando um Complemento de Cluster.
Para obter mais informações sobre o cert-manager, consulte a documentação cert-manager.io.
Observe que a instalação do controlador de entrada nativo do OCI como um complemento de cluster falhará se você ainda não tiver instalado o cert-manager, seja como um produto de código-fonte aberto ou como um complemento de cluster.