Documentação do Oracle Cloud Infrastructure

Pré-requisitos para implantar o Controlador de Entrada Nativo do OCI como um Programa Standalone

Descubra o que você precisa fazer para poder implantar o controlador de entrada nativo do OCI como um programa independente 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 programa independente:

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 selecione Identidade e Segurança. Em Identidade, selecione Domínios. Em Domínio de identidades, selecione 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. Selecione 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).

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

Concedendo Permissões ao Controlador de Entrada Nativo do OCI como um Programa Independente

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 selecione Identidade e Segurança. Em Identidade, selecione 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 leaf-certificate-versions
      • 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
      • use tag-namespaces (somente obrigatório se você quiser que o controlador de entrada nativo do OCI aplique tags definidas a balanceadores de carga. Consulte Aplicando tags definidas ao balanceador de carga)
    • <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 leaf-certificate-versions 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>
Allow <group|dynamic-group> <subject-name> to use tag-namespaces 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 leaf-certificate-versions 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
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to use tag-namespaces 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 leaf-certificate-versions
      • 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
      • use tag-namespaces (somente obrigatório se você quiser que o controlador de entrada nativo do OCI aplique tags definidas a balanceadores de carga. Consulte Aplicando tags definidas ao balanceador de carga)
    • <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 leaf-certificate-versions 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>'}
Allow any-user to use tag-namespaces 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.

Instalando a CLI do Helm para Instalar o Controlador de Entrada Nativo do OCI como um Programa Standalone

O Helm é um gerenciador de pacotes para o Kubernetes. O Helm é comumente usado para criar, empacotar, configurar e implantar aplicativos do Kubernetes combinando arquivos de configuração em um único pacote reutilizável chamado gráfico Helm. Os gráficos são empacotados e distribuídos em um formato de arquivo conhecido como arquivo de prontuários. Um gráfico contém as informações necessárias para instalar um conjunto de recursos do Kubernetes em um cluster do Kubernetes. Um gráfico inclui:

  • um arquivo chart.yaml, descrevendo o aplicativo,
  • um arquivo values.yaml, fornecendo valores padrão para parâmetros do aplicativo
  • modelos de arquivos usados pelo aplicativo
  • outras dependências

O Helm também tem um cliente de linha de comando, a CLI do Helm (às vezes chamada de helm, todas em letras minúsculas)

Para instalar o controlador de entrada nativo do OCI como um programa independente, o controlador de entrada nativo do OCI é disponibilizado como um gráfico Helm. Para poder instalar o gráfico do controlador de entrada nativo do OCI, primeiro instale a CLI do Helm.

Para instalar a CLI do Helm, siga as instruções na documentação de instalação do Helm para fazer download e extrair o arquivo compactado zip ou tar.gz apropriado.

Clonando o Repositório do Controlador de Entrada Nativo do OCI e Definindo Parâmetros em values.yaml

Para clonar o controlador de entrada nativo do OCI e definir parâmetros em values.yaml em preparação para instalar o controlador de entrada nativo do OCI como um programa independente:

  1. Clone o repositório do controlador de entrada nativo do OCI de GitHub digitando:
    git clone https://github.com/oracle/oci-native-ingress-controller
  2. No repositório Git local, navegue até o diretório oci-native-ingress-controller e abra o arquivo values.yaml em um editor de texto.
  3. No arquivo values.yaml, defina o parâmetro compartment_id como o OCID do compartimento no qual o controlador de entrada nativo do OCI deve criar o balanceador de carga e o certificado do OCI. Por exemplo:
    compartment_id: "ocid1.compartment.oc1..aaaaaaaa______ddq"
  4. No arquivo values.yaml, defina o parâmetro subnet_id como o OCID da sub-rede do balanceador de carga. Por exemplo:
    subnet_id: "ocid1.subnet.oc1.iad.aaaaaaaa______dba"
  5. No arquivo values.yaml, defina o parâmetro cluster_id como o OCID do cluster. Por exemplo:
    cluster_id: "ocid1.cluster.oc1.iad.aaaaaaaa______ska"
  6. No arquivo values.yaml, especifique como o controlador de entrada nativo do OCI deve acessar serviços e recursos do OCI da seguinte forma:
  7. (opcional) Se você quiser executar várias instâncias do controlador de entrada nativo do OCI por motivos de disponibilidade, altere o valor de replicaCount no arquivo values.yaml. Por exemplo:
    replicaCount: 3
    Por padrão, replicaCount é definido como 1, o que significa que uma instância do controlador de entrada nativo do OCI é executada como um único pod. Para garantir a disponibilidade, talvez você queira aumentar o replicaCount (geralmente para 2 ou 3) para executar várias instâncias do controlador de entrada nativo do OCI como pods diferentes. Um pod é indicado como líder e atua como controlador de entrada nativo da OCI, enquanto os pods restantes aguardam em um estado passivo. Se o líder posteriormente ficar indisponível, um dos outros pods será nomeado como líder e atuará como controlador de entrada nativo do OCI.
  8. Salve as alterações feitas no arquivo values.yaml e feche o arquivo.
  9. Se quiser que o controlador de entrada nativo do OCI acesse serviços e recursos do OCI usando um controlador de identidade de carga de trabalho, defina variáveis de ambiente adicionais da seguinte forma:
    1. No repositório Git local, navegue até o diretório oci-native-ingress-controller/templates e abra o arquivo deployment.yaml em um editor de texto.
    2. No arquivo deployment.yaml, defina as seguintes variáveis de ambiente, conforme mostrado: 
        env:
    - name: OCI_RESOURCE_PRINCIPAL_VERSION
      value: "2.2"
    - name: OCI_RESOURCE_PRINCIPAL_REGION
      value: "us-ashburn-1"
    3. Salve as alterações feitas no arquivo deployment.yaml e feche o arquivo.