Configurando o Controlador de Entrada Nativa do OCI

Para especificar como o balanceador de carga do OCI criado pelo controlador de entrada nativo do OCI (instalado como programa independente ou como complemento de cluster) roteia as solicitações de entrada, especifique regras de roteamento no manifesto Ingress.

kind: Ingress
...
spec:
  rules:
  - host: "foo.bar.com"
    http:
      paths:
        - pathType: Prefix
          path: /
          backend:
            serviceName: ServiceA
            servicePort: 80

kind: Ingress
...
spec:
  rules:
    - http:
      paths:
        - pathType: Prefix
          path: /app1
          backend:
            serviceName: ServiceA
            servicePort: 80
        - pathType: Prefix
          path: /app2
          backend:
            serviceName: ServiceB
            servicePort: 443

kind: Ingress
...
spec:
  rules:
  - host: "foo.bar.com"
    http:
      paths:
        - pathType: Prefix
          path: /app1
          backend:
            serviceName: foo
            servicePort: 80

kind: Ingress
...
spec:
  rules:
    - http:
      paths:
        - pathType: Prefix
          path: /app1
          backend:
            serviceName: ServiceA
            servicePort: 80
        - pathType: Prefix
          path: /app2
          backend:
            serviceName: ServiceB
            servicePort: 443
  defaultBackend:
    service:
      name: ServiceC
      port:
        number: 8080

Você pode adicionar anotações aos manifestos de recursos IngressClass ou Ingress para personalizar o comportamento do controlador de entrada nativo do OCI (instalado como um programa independente ou como um complemento de cluster).

As portas de prontidão do pod são condições adicionais incluídas em um manifesto de pod para indicar que um pod está pronto para receber tráfego. Os portões de prontidão do pod permitem implementar verificações de prontidão personalizadas complexas e podem ajudar a obter tempo de inatividade zero durante implantações contínuas. Para obter mais informações, consulte detalhes de preparação do pod na documentação do Kubernetes.

Ao usar o controlador de entrada nativo do OCI (como um programa independente ou como complemento de cluster) com um cluster que tenha rede de pod nativo da VCN como o tipo de rede, você pode especificar que o controlador de entrada nativo do OCI deve injetar um portão de preparação de pod na especificação de pod de cada pod criado em um namespace específico. Observe que você não pode usar o controlador de entrada nativo do OCI para injetar portas de prontidão de pod em especificações de pod se o cluster tiver Sobreposição de canal como o tipo de rede.

Especifique se o controlador de entrada nativo do OCI deve injetar um portão de preparação de pod na especificação de pod de cada pod criado em um namespace específico digitando:

kubectl label ns <namespace> podreadiness.ingress.oraclecloud.com/pod-readiness-gate-inject=enabled

O controlador de entrada nativo do OCI injeta uma condição na especificação de pod de cada pod criado no namespace. Por exemplo:

kind: Pod
...
    spec:
      readinessGates:
      - conditionType: podreadiness.ingress.oraclecloud.com/k8s_6b5b1b3a38

kubectl get pods -o wide -w

NAME                                             READY   STATUS    RESTARTS   AGE   IP            NODE          NOMINATED NODE   READINESS GATES
testecho-7cdcfff87f-b6xt4                        1/1     Running   0          35s   10.0.10.242   10.0.10.135   <none>           0/1
testecho-7cdcfff87f-b6xt4                        1/1     Running   0          72s   10.0.10.242   10.0.10.135   <none>           1/1

Você pode usar o controlador de entrada nativo do OCI (como um programa independente ou como complemento de cluster) para configurar listeners do balanceador de carga como listeners TCP. Cada listener TCP simplesmente encaminha o tráfego TCP recebido em uma porta específica para o serviço de backend especificado para essa porta em um manifesto de recursos Ingress, sem executar qualquer roteamento da camada de transporte 7.

Você define a anotação oci-native-ingress.oraclecloud.com/protocol para especificar que o controlador de entrada nativo do OCI deve criar um listener TCP para cada porta exclusiva incluída nas regras de roteamento em um manifesto de recursos Ingress.

Para especificar que o controlador de entrada nativo do OCI deve criar listeners TCP:

1. Defina um novo recurso de entrada em um arquivo .yaml. Consulte Criar recurso de Entrada.
2. Na seção metadata:, adicione um elemento annotations: e defina a anotação oci-native-ingress.oraclecloud.com/protocol como TCP, no formato:

   kind: Ingress
   metadata:
     name: <i-name>
     annotations:
       oci-native-ingress.oraclecloud.com/protocol: TCP
   spec:
   ...

   em que name: <i-name> é sua opção de nome para o recurso de entrada.

   Por exemplo:

   kind: Ingress
   metadata:
     name: ingress-pass-through
     annotations:
       oci-native-ingress.oraclecloud.com/protocol: TCP
   spec:
   ...

3. Na seção rules: do manifesto de recursos Ingress, adicione uma regra para cada listener que deve receber tráfego TCP:
   • (recomendado) Defina paths.pathType como ImplementationSpecific.
   • Defina paths.backend.service.name como o nome do serviço de backend.
   • Defina paths.backend.service.port.number como a porta na qual escutar o tráfego TCP e para a qual encaminhar o tráfego TCP.

   Por exemplo, se você quiser que um listener TCP na porta 8080 encaminhe o tráfego TCP para my-first-svc:8080 e um listener TCP na porta 8081 encaminhe o tráfego TCP para my-second-svc:8081, poderá configurar um manifesto de recursos Ingress da seguinte forma:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: ingress-pass-through
     annotations:
       oci-native-ingress.oraclecloud.com/protocol: TCP
   spec:
     rules:
       - http:
           paths:
             - pathType: ImplementationSpecific
               backend:
                 service:
                   name: my-first-svc
                   port:
                     number: 8080
       - http:
           paths:
             - pathType: ImplementationSpecific
               backend:
                 service:
                   name: my-second-svc
                   port:
                     number: 8081 
   

4. Crie o recurso digitando kubectl create -f <filename>.yaml

Você pode usar o controlador de entrada nativo do OCI (como um programa independente ou como complemento de cluster) para oferecer suporte à comunicação HTTPS segura. Usando o controlador de entrada nativo do OCI, você pode configurar listeners e conjuntos de backend do balanceador de carga do OCI para tratar o tráfego criptografado usando TLS (anteriormente SSL).

Ao usar o controlador de entrada nativo do OCI para oferecer suporte à comunicação HTTPS, você tem duas opções:

• Opção 1: O Controlador de Entrada Nativo do OCI obtém certificado do serviço Certificates usando um segredo do Kubernetes: Você cria um segredo do Kubernetes e especifica o nome do segredo em um manifesto de recursos Ingress. O controlador de entrada nativo do OCI usa o segredo do Kubernetes para obter um certificado e um pacote de CAs (pacote de Autoridade de Certificação) do serviço OCI Certificates. O controlador de entrada nativo do OCI associa o certificado e o pacote de CAs ao listener e ao conjunto de backend.
• Opção 2: Você obtém certificado do serviço Certificates: Você mesmo cria manualmente um certificado no serviço OCI Certificates. Em seguida, especifique o OCID do certificado no manifesto do recurso Ingress como uma anotação. O controlador de entrada nativo do OCI associa o certificado ao listener e ao conjunto de backend.

Ao tratar o tráfego HTTPS, o balanceador de carga do OCI criado pelo controlador de entrada nativo do OCI implementa TLS de ponta a ponta por padrão. O balanceador de carga usa certificados para aceitar uma solicitação criptografada TLS de um cliente e, em seguida, usa regras de roteamento para encaminhar a solicitação ao conjunto de backend apropriado. O conjunto de backend cria uma nova conexão TLS com backends em execução no cluster (usando o pacote de CAs como autoridade confiável para a nova conexão).

Observe o seguinte:

• Se você excluir um recurso IngressClass, o controlador de entrada nativo do OCI excluirá o balanceador de carga que ele criou (ou excluirá o balanceador de carga existente especificado pela anotação oci-native-ingress.oraclecloud.com/id). No entanto, observe que o controlador de entrada não exclui recursos criados no serviço OCI Certificates. Você é responsável por excluir esses recursos de serviço de Certificados. Em particular, se você especificou um segredo do Kubernetes no manifesto de recursos Ingress, observe que você é responsável por excluir todos os recursos do serviço Certificates que o controlador de entrada nativo do OCI criou para você.
• Os certificados obtidos do serviço OCI Certificates do tipo Importado não podem ser alternados automaticamente. Se você quiser que os certificados sejam alternados automaticamente, obtenha manualmente um certificado no serviço OCI Certificates especificando que deseja que o certificado seja emitido por uma CA interna do serviço Certificates (os certificados são do tipo Emitido por CA interna). Você pode configurar certificados do tipo Emitido por CA interna para serem alternados automaticamente.
• Se você especificar um segredo do Kubernetes no manifesto de recursos Ingress, observe que os certificados obtidos pelo controlador de entrada nativo do OCI do serviço Certificates são do tipo Importado e, portanto, não alternados automaticamente. Para rotacionar manualmente esses certificados de serviço de Certificados, primeiro crie um novo segredo do Kubernetes usando um novo par de chaves pública e privada TLS e um novo certificado. Em seguida, atualize o recurso Ingress com o nome do novo segredo. O controlador de entrada nativo do OCI obtém um novo certificado e um pacote de CAs do serviço Certificates e os associa ao listener e ao conjunto de backend (substituindo o certificado e o pacote de CAs anteriores).
• Um listener só pode ser associado a um certificado. Portanto, não crie vários recursos de entrada que tenham regras especificando a mesma combinação de serviço/porta de backend, mas em que os recursos de entrada usem certificados diferentes.
• Por padrão, o balanceador de carga do OCI criado pelo controlador de entrada nativo do OCI implementa TLS de ponta a ponta. O balanceador de carga encerra a solicitação de TLS no listener e uma nova conexão de TLS é estabelecida entre o conjunto de backend e os backends. No entanto, se os backends não estiverem executando um servidor HTTPS e, portanto, você quiser que a conexão entre o conjunto de backend e os backends esteja em texto simples, defina a anotação oci-native-ingress.oraclecloud.com/backend-tls-enabled como "false". Quando a anotação oci-native-ingress.oraclecloud.com/backend-tls-enabled é definida como "false", o balanceador de carga pode aceitar tráfego criptografado de um cliente, mas o tráfego entre o balanceador de carga e os backends não é criptografado.

Ao usar o controlador de entrada nativo do OCI (como um programa independente ou como complemento de cluster), você pode agregar todo o tráfego HTTP em uma única porta de listener e, da mesma forma, pode agregar todo o tráfego HTTPS em uma única porta.

Por padrão, o controlador de entrada nativo do OCI cria um listener do balanceador de carga do OCI para cada porta de serviço de backend definida em um manifesto Ingress. O controlador de entrada nativo do OCI também cria uma política de roteamento para cada porta do listener. No entanto, você pode usar a anotação oci-native-ingress.oraclecloud.com/http-listener-port e/ou a anotação oci-native-ingress.oraclecloud.com/https-listener-port para criar um único listener e uma política de roteamento para todas as solicitações HTTP e/ou um único listener e uma política de roteamento para todas as solicitações HTTPS.

Por exemplo, você pode definir uma entrada com regras para quatro serviços de backend, cada serviço atendendo em uma porta diferente, da seguinte forma:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: sample-ingress
spec:
  tls:
    - hosts:
        - "foo.bar.com3"
        - "foo.bar.com4"
      secretName: secret_name
  rules:
    - host: "foo.bar.com1"
      http:
        paths:
          - pathType: Prefix
            path: "/testecho1"
            backend:
              service:
                name: testecho1
                port:
                  number: 80
    - host: "foo.bar.com2"
      http:
        paths:
          - pathType: Prefix
            path: "/testecho2"
            backend:
              service:
                name: testecho2
                port:
                  number: 81
    - host: "foo.bar.com3"
      http:
        paths:
          - pathType: Prefix
            path: "/testecho3"
            backend:
              service:
                name: testecho3
                port:
                  number: 443
    - host: "foo.bar.com4"
      http:
        paths:
          - pathType: Prefix
            path: "/testecho4"
            backend:
              service:
                name: testecho4
                port:
                  number: 444 

Neste exemplo, o manifesto Ingress define quatro serviços:

• testecho1, fazendo listening na porta 80 para tráfego HTTP
• testecho2, fazendo listening na porta 81 para tráfego HTTP
• testecho3, fazendo listening na porta 443 para tráfego HTTPS
• testecho4, fazendo listening na porta 444 para tráfego HTTPS

Por padrão, o controlador de entrada nativo do OCI cria:

• Quatro listeners no balanceador de carga (dois listeners com listener nas portas 80 e 81 para tráfego HTTP e dois listeners com listener nas portas 443 e 444 para tráfego HTTPS).
• Quatro políticas de roteamento (uma para cada porta do listener).

Para simplificar a administração, você pode decidir ter um único listener atendendo ao tráfego HTTP e um único listener atendendo ao tráfego HTTPS, definindo anotações da seguinte forma:

oci-native-ingress.oraclecloud.com/http-listener-port: "100"
oci-native-ingress.oraclecloud.com/https-listener-port: "500"

Com as anotações definidas conforme mostrado, o controlador de entrada nativo do OCI cria:

• um único listener que está escutando tráfego HTTP na porta 100 e uma única política de roteamento para a porta 100 com caminhos para backends nas portas testecho1:80 e testecho2:81
• um único listener que faz listening do tráfego HTTPS na porta 500 e uma única política de roteamento para a porta 500 com caminhos para backends nas portas testecho3:443 e testecho4:444

Observe o seguinte:

• Você pode definir as anotações oci-native-ingress.oraclecloud.com/http-listener-port e oci-native-ingress.oraclecloud.com/https-listener-port independentemente umas das outras, para que não precise definir as duas anotações.

• Se o manifesto do recurso Ingress incluir a anotação oci-native-ingress.oraclecloud.com/certificate-ocid, o controlador de entrada nativo do OCI considerará todos os hosts a serem configurados para TLS. Nesse caso, o controlador de entrada nativo do OCI:

  • ignora a anotação oci-native-ingress.oraclecloud.com/http-listener-port (se presente no manifesto de recursos Ingress)
  • aplica a anotação oci-native-ingress.oraclecloud.com/https-listener-port (se presente no manifesto de recursos Ingress) para criar um único listener para todo o tráfego
• Independentemente das anotações oci-native-ingress.oraclecloud.com/http-listener-port e oci-native-ingress.oraclecloud.com/https-listener-port, o controlador de entrada nativo do OCI só cria listeners HTTP e/ou HTTPS (e políticas de roteamento correspondentes) se necessário para serviços de backend definidos no manifesto de recursos de Entrada. Por exemplo:
  • Se você incluir a anotação oci-native-ingress.oraclecloud.com/http-listener-port em um manifesto de recursos Ingress que não define um backend HTTP, o controlador de entrada nativo do OCI não criará um listener HTTP.
  • Se você incluir a anotação oci-native-ingress.oraclecloud.com/https-listener-port em um manifesto de recursos Ingress que não defina um backend HTTPS, o controlador de entrada nativo do OCI não criará um listener HTTPS.
  • Se você incluir anotações oci-native-ingress.oraclecloud.com/http-listener-port e oci-native-ingress.oraclecloud.com/https-listener-port em um manifesto de recursos Ingress que só define backends HTTP, o controlador de entrada nativo do OCI ignorará a anotação oci-native-ingress.oraclecloud.com/https-listener-port e não criará um listener HTTPS.
  • Se você incluir anotações oci-native-ingress.oraclecloud.com/http-listener-port e oci-native-ingress.oraclecloud.com/https-listener-port em um manifesto de recursos Ingress que defina apenas backends HTTPS, o controlador de entrada nativo do OCI ignorará a anotação oci-native-ingress.oraclecloud.com/http-listener-port e não criará um listener HTTP.