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:

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:

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:

  1. Crie um novo grupo dinâmico para conter as instâncias de computação que hospedam os nós de trabalho do cluster:
    1. 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.
    2. Selecione o compartimento ao qual as instâncias de computação pertencem.

    3. 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).

    4. 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'}
    5. Clique em Criar Grupo Dinâmico.

Antes de implantar o controlador de entrada nativo do OCI, você:

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:

  1. Se um usuário adequado ainda não existir, crie um usuário no serviço IAM (consulte Para criar um usuário).
  2. Se ainda não existir um grupo adequado, crie um grupo no serviço IAM (consulte Para criar um grupo).
  3. Adicione o usuário ao grupo (consulte Para adicionar um usuário a um grupo).
  4. Obtenha estes itens:

  5. Faça o upload da chave pública do par de chaves na Console. Consulte Como Fazer o Upload da Chave Pública.
  6. 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
  7. 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ê:

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:

  1. 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ê:

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:

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:

  1. Abra o menu de navegação e clique em Identidade e Segurança. Em Identidade, clique em Políticas.
  2. Siga as instruções em Para criar uma política e dê um nome à política (por exemplo, acme-oke-native-ingress-controller-policy).
  3. 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) ou dynamic-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 formato group id <group-ocid> ou dynamic-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 como compartment <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
    
  4. 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 como compartment <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.