This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Executar Aplicações

Execute e gerencie aplicações com estado e sem estado.

1: Executar uma Aplicação Sem Estado com um Deployment
2: Acessando a API do Kubernetes a partir de um Pod

1 - Executar uma Aplicação Sem Estado com um Deployment

Esta página mostra como executar uma aplicação usando um objeto Deployment do Kubernetes.

Objetivos

Criar uma instalação do nginx com um Deployment.
Usar o kubectl para listar informações sobre o Deployment.
Atualizar o Deployment.

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.9.

Para verificar a versão, digite kubectl version.

Criando e explorando uma instalação do nginx com um Deployment

Você pode executar uma aplicação criando um objeto Deployment do Kubernetes, e pode descrever um Deployment em um arquivo YAML. Por exemplo, este arquivo YAML descreve um Deployment que executa a imagem do contêiner nginx:1.14.2:

application/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # diz ao deployment para executar 2 pods que correspondam ao modelo
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Crie um Deployment com base no arquivo YAML:

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

Exiba informações sobre o Deployment:

kubectl describe deployment nginx-deployment

A saída é semelhante a esta:

Name:     nginx-deployment
Namespace:    default
CreationTimestamp:  Tue, 30 Aug 2016 18:11:37 -0700
Labels:     app=nginx
Annotations:    deployment.kubernetes.io/revision=1
Selector:   app=nginx
Replicas:   2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType:   RollingUpdate
MinReadySeconds:  0
RollingUpdateStrategy:  1 max unavailable, 1 max surge
Pod Template:
  Labels:       app=nginx
  Containers:
    nginx:
    Image:              nginx:1.14.2
    Port:               80/TCP
    Environment:        <none>
    Mounts:             <none>
  Volumes:              <none>
Conditions:
  Type          Status  Reason
  ----          ------  ------
  Available     True    MinimumReplicasAvailable
  Progressing   True    NewReplicaSetAvailable
OldReplicaSets:   <none>
NewReplicaSet:    nginx-deployment-1771418926 (2/2 replicas created)
No events.

Liste os Pods criados pelo Deployment:

kubectl get pods -l app=nginx

A saída é semelhante a esta:

NAME                                READY     STATUS    RESTARTS   AGE
nginx-deployment-1771418926-7o5ns   1/1       Running   0          16h
nginx-deployment-1771418926-r18az   1/1       Running   0          16h

Exiba informações sobre um Pod:
```
kubectl describe pod <pod-name>
```
onde <pod-name> é o nome de um dos seus Pods.

Atualizando o Deployment

Você pode atualizar o Deployment aplicando um novo arquivo YAML. Este arquivo YAML especifica que o Deployment deve ser atualizado para usar o nginx:1.16.1.

application/deployment-update.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1 # Atualiza a versão do nginx de 1.14.2 para 1.16.1
        ports:
        - containerPort: 80

Aplique o novo arquivo YAML:

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

Observe o Deployment criar Pods com novos nomes e excluir os Pods antigos:
```
kubectl get pods -l app=nginx
```

Escalonando a aplicação aumentando a contagem de réplicas

Você pode aumentar o número de Pods no seu Deployment aplicando um novo arquivo YAML. Este arquivo YAML define replicas como 4, o que especifica que o Deployment deve ter quatro Pods:

application/deployment-scale.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 4 # Atualiza a contagem de réplicas de 2 para 4
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1
        ports:
        - containerPort: 80

Aplique o novo arquivo YAML:

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

Verifique que o Deployment possui quatro Pods:

kubectl get pods -l app=nginx

A saída é semelhante a esta:

NAME                               READY     STATUS    RESTARTS   AGE
nginx-deployment-148880595-4zdqq   1/1       Running   0          25s
nginx-deployment-148880595-6zgi1   1/1       Running   0          25s
nginx-deployment-148880595-fxcez   1/1       Running   0          2m
nginx-deployment-148880595-rwovn   1/1       Running   0          2m

Excluindo um Deployment

Exclua o Deployment pelo nome:

kubectl delete deployment nginx-deployment

Controladores de Replicação -- a Forma Antiga

A forma preferida de criar uma aplicação replicada é usar um Deployment, que por sua vez utiliza um ReplicaSet. Antes do Deployment e do ReplicaSet serem adicionados ao Kubernetes, aplicações replicadas eram configuradas usando um Controlador de Replicação (ReplicationController).

Próximos passos

Saiba mais sobre objeto Deployment.

2 - Acessando a API do Kubernetes a partir de um Pod

Este guia demonstra como acessar a API do Kubernetes de dentro de um Pod.

Antes de você começar

Acessando a API de dentro de um Pod

Ao acessar a API a partir de um Pod, localizar e autenticar-se no servidor de API são processos ligeiramente diferentes do caso de um cliente externo.

A maneira mais fácil de usar a API do Kubernetes a partir de um Pod é utilizar uma das bibliotecas clientes oficiais. Essas bibliotecas conseguem descobrir automaticamente o servidor de API e autenticar-se.

Usando Bibliotecas Clientes Oficiais

De dentro de um Pod, as formas recomendadas de se conectar à API do Kubernetes são:

Para clientes em Go, utilize a biblioteca cliente oficial em Go. A função rest.InClusterConfig() lida automaticamente com a descoberta do host da API e a autenticação. Veja um exemplo aqui.
Para clientes em Python, utilize a biblioteca cliente oficial em Python. A função config.load_incluster_config() lida automaticamente com a descoberta do host da API e a autenticação. Veja um exemplo aqui.
Há diversas outras bibliotecas disponíveis. Consulte a página de Bibliotecas Clientes.

Em todos os casos, as credenciais da conta de serviço do Pod são utilizadas para se comunicar com segurança com o servidor de API.

Acessando diretamente a API REST

Enquanto estiver em execução em um Pod, seu contêiner pode criar uma URL HTTPS para o servidor de API do Kubernetes obtendo as variáveis de ambiente KUBERNETES_SERVICE_HOST e KUBERNETES_SERVICE_PORT_HTTPS. O endereço do servidor de API dentro do cluster também é publicado em um Service chamado kubernetes no namespace default, para que os Pods possam referenciar kubernetes.default.svc como um nome DNS para o servidor de API local.

Nota:

O Kubernetes não garante que o servidor de API tenha um certificado válido para o nome de host kubernetes.default.svc; no entanto, espera-se que a camada de gerenciamento apresente um certificado válido para o nome de host ou endereço IP representado por $KUBERNETES_SERVICE_HOST.

A forma recomendada de autenticar-se no servidor de API é com uma credencial de conta de serviço. Por padrão, um Pod é associado a uma conta de serviço, e uma credencial (token) para essa conta de serviço é colocada no sistema de arquivos de cada contêiner nesse Pod, em /var/run/secrets/kubernetes.io/serviceaccount/token.

Se disponível, um pacote de certificados é colocado no sistema de arquivos de cada contêiner em /var/run/secrets/kubernetes.io/serviceaccount/ca.crt, e deve ser utilizado para verificar o certificado de serviço do servidor de API.

Por fim, o namespace padrão a ser usado para operações da API com escopo de namespace é colocado em um arquivo em /var/run/secrets/kubernetes.io/serviceaccount/namespace em cada contêiner.

Usando o kubectl proxy

Se você quiser consultar a API sem utilizar uma biblioteca cliente oficial, pode executar o kubectl proxy como o comando de um novo contêiner sidecar no Pod. Dessa forma, o kubectl proxy irá se autenticar na API e expô-la na interface localhost do Pod, permitindo que outros contêineres no Pod a utilizem diretamente.

Sem usar um proxy

É possível evitar o uso do kubectl proxy passando o token de autenticação diretamente para o servidor de API. O certificado interno garante a segurança da conexão.

# Aponte para o nome de host interno do servidor de API
APISERVER=https://kubernetes.default.svc

# Caminho para o token da Conta de Serviço
SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount

# Ler o namespace deste Pod
NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)

# Ler o token de portador da Conta de Serviço
TOKEN=$(cat ${SERVICEACCOUNT}/token)

# Referenciar a autoridade certificadora (CA) interna
CACERT=${SERVICEACCOUNT}/ca.crt

# Explorar a API com o TOKEN
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api

A saída será semelhante a esta:

{
  "kind": "APIVersions",
  "versions": ["v1"],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}