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:
- é 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
- é 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
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
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.
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.