Essa é a versão completa de impressão dessa seção Clique aqui para imprimir.

Retornar à visualização normal.

Acessando Aplicações em um Cluster

Configurar balanceamento de carga, redirecionamento de porta, ou configuração de firewall ou DNS para acessar aplicativos em um cluster.

1 - Use o redirecionamento de porta para acessar aplicativos em um cluster.

Esta página mostra como usar o kubectl port-forward para se conectar a um servidor MongoDB em execução em um cluster Kubernetes. Esse tipo de conexão pode ser útil para depuração de bancos de dados.

Antes de você começar

  • Você precisa ter um cluster do Kubernetes e a ferramenta de linha de comando kubectl deve estar configurada para se comunicar com seu cluster. É recomendado executar esse tutorial em um cluster com pelo menos dois nós que não estejam atuando como hosts de camada de gerenciamento. Se você ainda não possui um cluster, pode criar um usando o minikube ou pode usar um dos seguintes ambientes:

    O seu servidor Kubernetes deve estar numa versão igual ou superior a v1.10. Para verificar a versão, digite kubectl version.
  • Instale o MongoDB Shell.

Criando a implantação e o serviço do MongoDB

  1. Crie uma Implantação que execute o MongoDB:

    kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
    

    A saída de um comando bem-sucedido verifica que a implantação foi criada:

    deployment.apps/mongo criado
    

    Visualize o status do pod para verificar se ele está pronto:

    kubectl get pods
    

    A saída exibe o pod criado:

    NAME                     READY   STATUS    RESTARTS   AGE
    mongo-75f59d57f4-4nd6q   1/1     Em execução   0          2m4s
    

    Visualize o status da implantação:

    kubectl get deployment
    

    A saída exibe que a implantação foi criada:

    NAME    READY   UP-TO-DATE   AVAILABLE   AGE
    mongo   1/1     1            1           2m21s
    

    A implantação gerencia automaticamente um conjunto de réplicas. Visualize o status do conjunto de réplicas usando:

    kubectl get replicaset
    

    Visualize o status do conjunto de réplicas usando:

    NAME               DESIRED   CURRENT   READY   AGE
    mongo-75f59d57f4   1         1         1       3m12s
    
  2. Crie um serviço para expor o MongoDB na rede:

    kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
    

    A saída de um comando bem-sucedido verifica que o serviço foi criado:

    service/mongo criado
    

    Verifique o serviço criado::

    kubectl get service mongo
    

    A saída exibe o serviço criado:

    NAME    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
    mongo   ClusterIP   10.96.41.183   <none>        27017/TCP   11s
    
  3. Verifique se o servidor MongoDB está sendo executado no Pod e ouvindo a porta 27017:

    # Altere mongo-75f59d57f4-4nd6q para o nome do Pod
    kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
    

    A saída exibe a porta para o MongoDB nesse Pod:

    27017
    

    27017 é a porta TCP alocada ao MongoDB na internet.

Encaminhe uma porta local para uma porta no Pod

  1. kubectl port-forward permite usar o nome do recurso, como o nome do pod, para selecionar um pod correspondente para encaminhar a porta.

    # Altere mongo-75f59d57f4-4nd6q para o nome do Pod
    kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017
    

    que é o mesmo que

    kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017
    

    ou

    kubectl port-forward deployment/mongo 28015:27017
    

    ou

    kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017
    

    ou

    kubectl port-forward service/mongo 28015:27017
    

    Qualquer um dos comandos acima funciona. A saída é semelhante a esta:

    Encaminhamento de 127.0.0.1:28015 -> 27017
    Encaminhamento de [::1]:28015 -> 27017
    
  2. Inicie a interface de linha de comando do MongoDB:

    mongosh --port 28015
    
  3. No prompt de comando do MongoDB, digite o comando ping:

    db.runCommand( { ping: 1 } )
    

    Uma solicitação de ping bem-sucedida retorna:

    { ok: 1 }
    

Opcionalmente, deixe kubectl escolher a porta local

Se você não precisa de uma porta local específica, pode permitir que o kubectl escolha e reserve a porta local e, assim, evitar ter que gerenciar conflitos de porta local, com a sintaxe ligeiramente mais simples:

kubectl port-forward deployment/mongo :27017

A ferramenta kubectl encontra um número de porta local que não está em uso (evitando números de porta baixos, porque esses podem ser usados por outras aplicações). A saída é semelhante a:

Encaminhamento de 127.0.0.1:63753 -> 27017
Encaminhamento de [::1]:63753 -> 27017

Discussão

As conexões feitas à porta local 28015 são encaminhadas para a porta 27017 do Pod que está executando o servidor MongoDB. Com esta conexão em vigor, você pode usar seu local de trabalho para depurar o banco de dados que está sendo executado no Pod.

Próximos passos

Saiba mais sobre kubectl port-forward.

2 - Comunicação entre contêineres no mesmo pod usando um volume compartilhado

Esta página mostra como usar um Volume para realizar a comunicação entre dois contêineres rodando no mesmo Pod. Veja também como permitir que processos se comuniquem por compartilhamento de namespace do processo entre os contêineres.

Antes de você começar

Você precisa ter um cluster do Kubernetes e a ferramenta de linha de comando kubectl deve estar configurada para se comunicar com seu cluster. É recomendado executar esse tutorial em um cluster com pelo menos dois nós que não estejam atuando como hosts de camada de gerenciamento. Se você ainda não possui um cluster, pode criar um usando o minikube ou pode usar um dos seguintes ambientes:

Para verificar a versão, digite kubectl version.

Criando um pod que executa dois contêineres

Neste exercício, você cria um Pod que executa dois contêineres. Os dois contêineres compartilham um volume que eles podem usar para se comunicar. Aqui está o arquivo de configuração para o Pod:

apiVersion: v1
kind: Pod
metadata:
  name: two-containers
spec:

  restartPolicy: Never

  volumes:
  - name: shared-data
    emptyDir: {}

  containers:

  - name: nginx-container
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/nginx/html

  - name: debian-container
    image: debian
    volumeMounts:
    - name: shared-data
      mountPath: /pod-data
    command: ["/bin/sh"]
    args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]

No arquivo de configuração, você pode ver que o Pod tem um shared-data chamado shared-data.

O primeiro contêiner listado no arquivo de configuração executa um servidor nginx. O caminho de montagem para o volume compartilhado é /usr/share/nginx/html. O segundo contêiner é baseado na imagem debian e tem um caminho de montagem /pod-data. O segundo contêiner executa o seguinte comando e é encerrado.

echo Hello from the debian container > /pod-data/index.html

Observe que o segundo contêiner grava o arquivo index.html no diretório raiz do servidor nginx.

Crie o Pod e os dois contêineres:

kubectl apply -f https://k8s.io/examples/pods/two-container-pod.yaml

Veja as informações sobre o Pod e os contêineres:

kubectl get pod two-containers --output=yaml

Aqui está uma parte da saída:

apiVersion: v1
kind: Pod
metadata:
  ...
  name: two-containers
  namespace: default
  ...
spec:
  ...
  containerStatuses:

  - containerID: docker://c1d8abd1 ...
    image: debian
    ...
    lastState:
      terminated:
        ...
    name: debian-container
    ...

  - containerID: docker://96c1ff2c5bb ...
    image: nginx
    ...
    name: nginx-container
    ...
    state:
      running:
    ...

Você pode ver que o contêiner debian foi encerrado e o contêiner nginx ainda está em execução.

Obtenha um shell para o contêiner nginx:

kubectl exec -it two-containers -c nginx-container -- /bin/bash

Em seu shell, verifique que o nginx está em execução:

root@two-containers:/# apt-get update
root@two-containers:/# apt-get install curl procps
root@two-containers:/# ps aux

A saída é semelhante a esta:

USER       PID  ...  STAT START   TIME COMMAND
root         1  ...  Ss   21:12   0:00 nginx: master process nginx -g daemon off;

Lembre-se de que o contêiner debian criou o arquivo index.html no diretório raiz do nginx. Use curl para enviar uma solicitação GET para o servidor nginx:

root@two-containers:/# curl localhost

A saída mostra que o nginx responde com uma página da web escrita pelo contêiner debian:

Hello from the debian container

Discussão

O principal motivo pelo qual os pods podem ter vários contêineres é oferecer suporte a aplicações extras que apoiam uma aplicação principal. Exemplos típicos de aplicativos auxiliares são extratores de dados, aplicações para envio de dados e proxies. Aplicativos auxiliares e primários geralmente precisam se comunicar uns com os outros. Normalmente, isso é feito por meio de um sistema de arquivos compartilhado, conforme mostrado neste exercício, ou por meio da interface de rede de loopback, localhost. Um exemplo desse padrão é um servidor web junto com um programa auxiliar que consulta um repositório Git para novas atualizações.

O volume neste exercício fornece uma maneira dos contêineres se comunicarem durante a vida útil do Pod. Se o Pod for excluído e recriado, todos os dados armazenados no volume compartilhado serão perdidos.

Próximos passos

3 - Configurar DNS em um cluster

O Kubernetes oferece um complemento de DNS para os clusters, que a maioria dos ambientes suportados habilitam por padrão. Na versão do Kubernetes 1.11 e posterior, o CoreDNS é recomendado e instalado por padrão com o kubeadm.

Para mais informações sobre como configurar o CoreDNS para um cluster Kubernetes, veja Personalização do Serviço de DNS. Para ver um exemplo que demonstra como usar o DNS do Kubernetes com o kube-dns, consulte Plugin de exemplo para DNS.