Acessando clusters

Esse tópico fala sobre diversas maneiras de interagir com clusters.

Acessando pela primeira vez com kubectl

Se estiver acessando o Kubernetes API pela primeira vez, recomendamos usar a CLI do Kubernetes, kubectl.

Para acessar um cluster, você precisa saber a localização do cluster e ter credenciais para acessá-lo. Geralmente, isso é configurado automaticamente quando você trabalha com um Guia de instalação ou outra pessoa configurou o cluster e forneceu a você credenciais e uma localização.

Verifique o local e as credenciais que o kubectl conhece com esse comando:

kubectl config view

Muitos dos exemplos fornecem uma introdução ao uso do kubectl e a documentação completa pode ser encontrada no guia de referência do kubectl.

Acessando diretamente a API REST

O Kubectl lida com a localização e a autenticação no servidor de API. Se você quiser acessar diretamente a API REST com um cliente http como curl ou wget, ou um navegador, há várias maneiras de localizar e autenticar:

• Executar o kubectl no modo proxy.
  • Método recomendado.
  • Usa a localização previamente armazenada do servidor da API.
  • Verifica a identidade do apiserver usando um certificado autoassinado. Não há possibilidade de ataque MITM (Man-In-The-Middle).
  • Autentica-se no servidor da API.
  • No futuro, poderá fazer balanceamento de carga inteligente no lado do cliente, e transferência em caso de falha.
• Forneça o local e as credenciais diretamente para o cliente http.
  • Método alternativo.
  • Funciona com alguns tipos de código de cliente que são confundidos pelo uso de um proxy.
  • É necessário importar um certificado raiz em seu navegador para se proteger contra ataque MITM (Man-In-The-Middle).

Usando o kubectl proxy

O comando a seguir executa o kubectl em um modo em que ele atua como um proxy reverso. Ele lida com localização do apiserver e da autenticação. Execute-o desta forma:

kubectl proxy --port=8080

Consulte kubectl proxy para obter mais detalhes.

Em seguida, você pode explorar a API com curl, wget ou um navegador, substituindo localhost por [::1] para IPv6, da seguinte forma:

curl http://localhost:8080/api/

O resultado é semelhante a este:

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

Sem kubectl proxy

Use kubectl apply e kubectl describe secret... para criar um token para a conta de serviço padrão com grep/cut:

Primeiro, crie o Secret, solicitando um token para a ServiceAccount padrão:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: default-token
  annotations:
    kubernetes.io/service-account.name: default
type: kubernetes.io/service-account-token
EOF

Em seguida, aguarde até que o controlador de token preencha o Secret com um token:

while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
  echo "waiting for token..." >&2
  sleep 1
done

Recupere e use o token gerado:

APISERVER=$(kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " ")
TOKEN=$(kubectl describe secret default-token | grep -E '^token' | cut -f2 -d':' | tr -d " ")

curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

O resultado é semelhante a este:

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

Usando jsonpath:

APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)

curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

O resultado é semelhante a este:

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

Os exemplos acima usam a opção --insecure. Isso deixa o cluster sujeito a ataques MITM. Quando o kubectl acessa o cluster, ele usa um certificado raiz guardado e certificados de cliente para acessar o servidor. (Esses certificados são instalados no diretório ~/.kube). Como os certificados do cluster normalmente são autoassinados, pode ser necessária uma configuração especial para que seu cliente http use o certificado raiz.

Em alguns clusters, o servidor da API não requer autenticação; ele pode servir no localhost ou estar protegido por um firewall. Não há um padrão para isso. A página Controlando Acesso à API do Kubernetes
descreve como um administrador de cluster pode configurar isso.

Acesso programático à API

O Kubernetes suporta oficialmente as bibliotecas de clientes Go e Python.

Cliente Go

• Para obter a biblioteca, execute o seguinte comando: go get k8s.io/client-go@kubernetes-<kubernetes-version-number>, consulte INSTALL.md para obter instruções detalhadas de instalação. Consulte https://github.com/kubernetes/client-go para ver quais versões são compatíveis.
• Escreva um aplicativo utilizando o cliente Go. Observe que ela define seus próprios objetos de API, portanto, se necessário, importe as definições de API do cliente Go em vez de importá-las do repositório principal. Por exemplo, import "k8s.io/client-go/kubernetes" está correto.

O cliente Go pode usar o mesmo arquivo kubeconfig como a CLI do kubectl faz, para localizar e autenticar ao apiserver. Veja esse exemplo.

Se o aplicativo for disponibilizado como um pod no cluster, consulte a próxima seção.

Cliente Python

Para usar o cliente Python, execute o seguinte comando: pip install kubernetes. Consulte a página Python Client Library para obter mais opções de instalação.

O cliente Python pode usar o mesmo arquivo kubeconfig que a ferramenta kubectl utiliza para localizar e autenticar ao servidor da API. Veja esse exemplo.

Outras bibliotecas

Existem bibliotecas de clientes para acessar a API utilizando outras linguagens. Consulte a documentação de outras bibliotecas para saber como elas se autenticam.

Acessando a API a partir de um pod

Ao acessar a API a partir de um pod, a localização e a autenticação para o servidor de API são um pouco diferentes.

Consulte Acessando a API a partir de um pod para obter mais detalhes.

Acessando serviços em execução no cluster

A seção anterior descreve como se conectar ao servidor da API do Kubernetes. Para obter informações sobre como se conectar a outros serviços em execução em um cluster do Kubernetes, consulte Acessando serviços em execução em clusters.

Solicitação de redirecionamentos

Os recursos de redirecionamento foram descontinuados e removidos. Em vez disso, use um proxy (veja abaixo).

Tantos proxies

Há vários proxies diferentes que você pode encontrar ao usar o Kubernetes:

1. O kubectl proxy:

   • é executado no computador de um usuário ou em um pod
   • cria um proxy de um endereço localhost para o servidor da API do Kubernetes
   • a conexão do cliente para o proxy usa HTTP
   • a conexão do proxy para o servidor da API usa HTTPS
   • localiza o apiserver
   • adiciona cabeçalhos de autenticação

2. O proxy do servidor da API:

   • é um bastião incorporado ao apiserver
   • conecta um usuário fora do cluster aos IPs do cluster que, de outra forma, poderiam não ser acessíveis
   • é executado no processo do servidor da API
   • cliente para proxy usa HTTPS (ou http se o servidor da API estiver configurado dessa forma)
   • a conexão do proxy para o destino pode usar HTTP ou HTTPS, conforme escolhido pelo proxy usando as informações disponíveis
   • pode ser usado para acessar um Nó, Pod ou Serviço
   • faz o balanceamento de carga quando usado para acessar um serviço

3. O kube proxy:

   • é executado em cada nó
   • proxy de UDP e TCP
   • não entende HTTP
   • fornece balanceamento de carga
   • é usado apenas para acessar serviços

4. Um Proxy/balanceador de carga na frente do(s) servidor(es) da API:

   • a existência e a implementação variam de cluster para cluster (por exemplo, nginx)
   • fica entre todos os clientes e um ou mais servidores da API
   • atua como um balanceador de carga se houver vários servidores da API.

5. Balanceadores de carga de provedor de nuvem em serviços externos:

   • são fornecidos por alguns provedores de nuvem computacional (por exemplo, AWS ELB, Google Cloud Load Balancer)
   • são criados automaticamente quando o serviço Kubernetes tem o tipo LoadBalancer
   • usam somente UDP/TCP
   • a implementação varia de acordo com o provedor de nuvem.

Normalmente, os usuários do Kubernetes não precisam se preocupar com nada além dos dois primeiros tipos. O administrador do cluster normalmente garantirá que os últimos tipos sejam configurados corretamente.