Skip to main content


Minikube​

O Minikube é um dos métodos mais fáceis, flexíveis e populares para executar um cluster Kubernetes local multifuncional ou de vários nodes, isolado por máquinas virtuais (VM) ou contêineres, executado diretamente em nossos computadores. O Minikube é a ferramenta responsável pela instalação de componentes do Kubernetes, inicialização do cluster e desmontagem do cluster quando não for mais necessário. Ele inclui recursos adicionais destinados a facilitar a interação do usuário com o cluster Kubernetes, mas, mesmo assim, inicializa para nós um cluster Kubernetes totalmente funcional e não produtivo, extremamente conveniente para fins de aprendizagem.


Para aproveitar plenamente todos os recursos que o Minikube oferece, um Hypervisor Tipo-2 ou um Runtime de Contêiner deve ser instalado na estação de trabalho local, para funcionar em conjunto com o Minikube. O papel do hypervisor ou do runtime de contêiner é oferecer uma infraestrutura isolada para os componentes do cluster Kubernetes do Minikube, que seja facilmente reproduzível, fácil de usar e desmontar.


Essa separação dos componentes do cluster do nosso ambiente garante que, uma vez que não sejam mais necessários, os componentes do Minikube possam ser removidos com segurança, sem deixar alterações de configuração no nosso computador, sem deixar vestígios de sua existência. Isso não significa, no entanto, que somos responsáveis pelo provisionamento de qualquer VM ou contêiner com sistemas operacionais convidados com a ajuda do hypervisor ou runtime de contêiner. O Minikube inclui os adaptadores necessários para interagir diretamente com o software de isolamento escolhido para construir toda a sua infraestrutura, desde que o Hypervisor Tipo-2 ou Runtime de Contêiner esteja instalado na nossa estação de trabalho.


O Minikube é construído com base nas capacidades da biblioteca libmachine, originalmente projetada pelo Docker para construir hosts de contêineres de Máquina Virtual em qualquer infraestrutura física. Com o tempo, o Minikube tornou-se muito flexível, suportando vários hypervisors e runtimes de contêiner, dependendo do sistema operacional nativo onde ele será usado.


O Minikube também pode ser instalado sem um software de isolamento, em bare-metal, o que pode resultar em alterações permanentes de configuração no sistema operacional host. Para evitar tais alterações permanentes de configuração, uma segunda forma de isolamento pode ser alcançada instalando o Minikube dentro de uma Máquina Virtual provisionada com um Hypervisor Tipo-2 de sua escolha, e um sistema operacional convidado de desktop de sua escolha (com GUI habilitada).


O software de isolamento pode ser especificado pelo usuário com a opção --driver, caso contrário, o Minikube tentará encontrar um método preferido para o sistema operacional host da estação de trabalho.


Uma vez decidido o método de isolamento, o próximo passo é determinar o número necessário de nodes do cluster Kubernetes e seus tamanhos em termos de CPU, memória e espaço em disco. O Minikube invoca o hypervisor de escolha para provisionar a(s) VM(s) de infraestrutura que hospedarão o(s) node(s) do cluster Kubernetes, ou o runtime de escolha para rodar o(s) contêiner(es) de infraestrutura que hospedarão o(s) node(s) do cluster.


Lembre-se de que o Minikube agora suporta clusters de único node all-in-one e clusters de múltiplos nodes. Independentemente do método de isolamento e dos tamanhos esperados do cluster e dos nodes, um cluster Kubernetes local do Minikube será impactado e/ou limitado pelos recursos físicos da estação de trabalho host. Devemos estar atentos às necessidades do sistema operacional host e de quaisquer utilitários que ele possa estar executando, depois às necessidades do hypervisor ou do runtime de contêiner, e finalmente aos recursos restantes que podem ser alocados para o nosso cluster Kubernetes.


Para um ambiente de aprendizado, as recomendações são que um node Kubernetes tenha no mínimo 2 núcleos de CPU (ou CPUs virtuais), pelo menos 2 GB de memória RAM (com 4 - 8 GB de RAM recomendados para uso ideal) e 20+ GB de espaço de armazenamento em disco. Ao migrar para um cluster maior e mais dinâmico de nível de produção, esses valores de recursos devem ser ajustados conforme necessário. Espera-se que os nodes do Kubernetes acessem a internet também, para atualizações de software, downloads de imagens de contêiner e para acessibilidade dos clientes.


Após a fase de provisionamento dos nodes, o Minikube invoca o kubeadm para inicializar os componentes do cluster Kubernetes dentro dos nodes provisionados anteriormente. Precisamos garantir que temos o hardware e o software necessários exigidos pelo Minikube para construir nosso ambiente.



Requisitos para executar o Minikube​

Veja os requisitos para executar o Minikube:

  • VT-x/AMD-v virtualization
    A virtualização VT-x/AMD-v pode precisar ser habilitada na estação de trabalho local para determinados hipervisores.

  • kubectl
    O cliente de linha de comando (CLI) kubectl é um binário usado para acessar e gerenciar qualquer cluster Kubernetes. Ele é instalado através do Minikube e acessado através do comando minikube kubectl, ou pode ser instalado separadamente e executado como uma ferramenta independente.

  • Type-2 hypervisor or container runtime
    Sem um driver especificado, o Minikube tentará encontrar um hipervisor instalado ou um runtime, na seguinte ordem de preferência (em um host Linux): docker, kvm2, podman, vmware e virtualbox. Se várias instalações de software de isolamento forem encontradas, como docker e virtualbox, o Minikube escolherá o docker em vez do virtualbox se nenhum driver desejado for especificado pelo usuário. Em hipervisores Linux VirtualBox, KVM2 e QEMU ou runtime Docker e Podman.

  • Conexão com a Internet na primeira execução do Minikube
    Isso é necessário para baixar pacotes, dependências, atualizações e obter imagens necessárias para inicializar os componentes do cluster Minikube Kubernetes. As execuções subsequentes do Minikube exigirão uma conexão com a Internet somente quando novas imagens de contêiner precisarem ser extraídas de um registro de contêiner público ou quando aplicativos em contêineres implantados precisarem disso para acessibilidade do cliente. Depois que uma imagem de contêiner for extraída, ela poderá ser reutilizada no cache de imagens de runtime do contêiner local sem uma conexão com a Internet.



Instalando o Minikube​

Vou instalar o Minikube na minha máquina física (Ubuntu 22.04) com o KVM.


Terminal
# Verifique o suporte de virtualização em um terminal (uma saída não vazia indica virtualização suportada):
$ grep -cE --color 'vmx|svm' /proc/cpuinfo 
6

# Faça o download do binário do Minikube:
$ curl -LO \
https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64

# Agora instale o binário no Path do Linux:
$ sudo install minikube-linux-amd64 /usr/local/bin/minikube && rm minikube-linux-amd64

# Agora inicie o Minikube:
$ minikube start --driver=kvm2
😄  minikube v1.33.1 on Ubuntu 22.04
✨  Using the kvm2 driver based on user configuration
💾  Downloading driver docker-machine-driver-kvm2:
    > docker-machine-driver-kvm2-...:  65 B / 65 B [---------] 100.00% ? p/s 0s
    > docker-machine-driver-kvm2-...:  13.46 MiB / 13.46 MiB  100.00% 7.25 MiB 
💿  Downloading VM boot image ...
    > minikube-v1.33.1-amd64.iso....:  65 B / 65 B [---------] 100.00% ? p/s 0s
    > minikube-v1.33.1-amd64.iso:  314.16 MiB / 314.16 MiB  100.00% 8.21 MiB p/
👍  Starting "minikube" primary control-plane node in "minikube" cluster
💾  Downloading Kubernetes v1.30.0 preload ...
    > preloaded-images-k8s-v18-v1...:  342.90 MiB / 342.90 MiB  100.00% 7.67 Mi
🔥  Creating kvm2 VM (CPUs=2, Memory=6000MB, Disk=20000MB) ...
🐳  Preparing Kubernetes v1.30.0 on Docker 26.0.2 ...
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔗  Configuring bridge CNI (Container Networking Interface) ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: default-storageclass, storage-provisioner
💡  kubectl not found. If you need it, try: 'minikube kubectl -- get pods -A'
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

# Agora com o comando virsh podemos ver que uma máquina virtual está em execução:
$ virsh list
 Id   Name       State
--------------------------
 1    minikube   running

# Verifique o status:
$ minikube status
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

# Para parar a máquina virtual, podemos usar o comando abaixo:
$ minikube stop
✋  Stopping node "minikube"  ...
🛑  1 node stopped.

# Para deletar a máquina virtual, podemos usar o comando abaixo:
$ minikube delete


Recursos avançados do Minikube​

Agora que sabemos como instalar o Minikube e usar ele com o KVM, vamos nos aprofundar no Minikube para entender algumas de suas funcionalidades mais avançadas.


O comando minikube start provisiona uma única VM chamada "minikube" (com perfil de hardware de CPUs=2, Memória=6GB, Disco=20GB) ou contêiner (Docker) para hospedar o cluster Kubernetes padrão de único node, sendo all-in-one. Uma vez que o node é provisionado, ele inicializa o Control Plane do Kubernetes (com a ferramenta padrão kubeadm) e instala a versão mais recente do runtime de contêiner padrão, Docker, que servirá como ambiente de execução para as aplicações containerizadas que implantaremos no cluster Kubernetes. O comando minikube start gera um cluster padrão "minikube" com as especificações descritas acima e armazenará essas especificações para que possamos reiniciar o cluster padrão sempre que desejarmos. O objeto que armazena as especificações do nosso cluster é chamado de perfil.


À medida que o Minikube evolui, suas funcionalidades e capacidades também se expandem. Com a introdução de perfis, o Minikube permite aos usuários criar clusters personalizados reutilizáveis que podem ser gerenciados a partir de um único cliente de linha de comando. O comando minikube profile permite visualizar o status de todos os nossos clusters em uma saída formatada em tabela. Supondo que tenhamos criado apenas o cluster padrão "minikube", podemos listar as propriedades que definem o perfil padrão com:


E se quisermos criar vários clusters reutilizáveis, com outros drivers (Docker ou Podman) para isolamento de nodes, ou diferentes versões do Kubernetes (v1.27.10 ou v1.28.1), outro runtime (cri-o ou containerd) e possivelmente 2, 3 ou mais nodes?


E se quisermos personalizar ainda mais o cluster com uma opção ou plugin de rede específico? O comando minikube start nos permite criar esses perfis personalizados com as flags --profile ou -p. Vários dos drivers de isolamento suportam a criação de VMs de node ou contêineres de node de tamanhos personalizados (não vou aprofundar nessa parte).


Abaixo estão alguns exemplos de comandos de start mais complexos que permitem a criação de clusters personalizados com Minikube. Eles assumem que o software de driver desejado (Docker e/ou Podman) foi instalado na estação de trabalho do host. Não há necessidade de baixar o CNI (plugin de rede) desejado ou o runtime de contêiner, eles serão configurados e habilitados pelo Minikube:


Terminal
# Inicia o Minikube com Podman, numa versão específica, com um perfil específico:
$ minikube start --kubernetes-version=v1.27.10 \
  --driver=podman --profile minipod

# Inicia o Minikube com docker, numa versão específica, com um perfil específico e com dois nodes:
$ minikube start --nodes=2 --kubernetes-version=v1.28.1 \
  --driver=docker --profile doubledocker

# O comando abaixo se difere por usar o subir a vm no VirtualBox,
# Além de informar configurações personalizadas de hardware:
$ minikube start --driver=virtualbox --nodes=3 --disk-size=10g \
  --cpus=2 --memory=6g --kubernetes-version=v1.27.12 --cni=calico \
  --container-runtime=cri-o -p multivbox

# Para mudar o perfil, basta usar o comando abaixo com o nome do perfil:
$ minikube profile PROFILE_NAME

A maioria dos comandos do Minikube, como start, stop, node, etc., são conscientes de perfil, o que significa que o usuário deve especificar explicitamente o cluster alvo do comando, através do nome do perfil. O cluster padrão do Minikube, no entanto, pode ser gerenciado implicitamente sem especificar seu nome de perfil.


Terminal
# Parando o cluster cluster_test explicitamente:
minikube stop --profile=cluster_test

# Reiniciando o cluster cluster_test explicitamente:
minikube start --profile=cluster_test

# Parando o cluster minikube padrão implicitamente:
minikube stop

# Reiniciando o cluster minikube padrão implicitamente:
minikube start

Para habilitar a auto-compleção do comando minikube no shell bash no Ubuntu, você pode seguir os passos abaixo:


Terminal
# Instale o pacote de auto-compleção:
$ sudo apt -y install bash-completion

# Adicione a auto-compleção do Minikube:
$ echo 'source <(minikube completion bash)' >> ~/.bashrc

# Recarregue o arquivo .bashrc:
$ source ~/.bashrc

# Se necessário, execute o comando abaixo:
minikube completion bash


Opções de uso do Minikube​

A tabela abaixo mostra alguns dos comandos mais usados do Minikube:

ComandoDescrição
minikube node listExibe os nodes de um cluster.
minikube ipExibe os IPs dos nodes do Cluster.


Acessando o Minikube​

Qualquer cluster Kubernetes em bom funcionamento pode ser acessado por meio de qualquer um dos seguintes métodos: ferramentas e scripts de Interface de Linha de Comando (CLI), Interface de Usuário baseada na Web (Web UI) a partir de um navegador da web, APIs a partir da CLI ou programaticamente. Esses métodos funcionam em todos os clusters Kubernetes.


  • Command Line Interface (CLI)
    O kubectl é o cliente de Interface de Linha de Comando (CLI) do Kubernetes para gerenciar recursos e aplicações do cluster. É muito flexível e fácil de integrar com outros sistemas, portanto, pode ser usado de forma independente ou como parte de scripts e ferramentas de automação. Uma vez que todas as credenciais necessárias e pontos de acesso ao cluster tenham sido configurados para o kubectl, ele pode ser usado remotamente de qualquer lugar para acessar um cluster.

    Usaremos o kubectl extensivamente para implantar aplicações, gerenciar e configurar recursos do Kubernetes.

  • Web-based User Interface (Web UI)
    O Kubernetes Dashboard fornece uma Interface de Usuário baseada na Web (Web UI) para interagir com um cluster Kubernetes para gerenciar recursos e aplicações containerizadas. Embora não seja tão flexível quanto a ferramenta de cliente CLI kubectl, ainda é uma ferramenta preferida para usuários que não são tão proficientes com a CLI.

  • APIs
    O principal componente do Control Plane do Kubernetes é o Servidor API, responsável por expor as APIs do Kubernetes. As APIs permitem que operadores e usuários interajam diretamente com o cluster. Usando tanto as ferramentas CLI quanto a Interface de Usuário do Dashboard, podemos acessar o Servidor API que está rodando no node do Control Plane para realizar várias operações e modificar o estado do cluster. O Servidor API é acessível através de seus endpoints por agentes e usuários que possuam as credenciais necessárias.

    Abaixo, podemos ver a representação da árvore de diretórios da API HTTP do Kubernetes:


    A imagem abaixo representa o HTTP API Directory Tree of Kubernetes. Fonte: Elaborado por kubernetes.io.

    HTTP API Directory Tree of Kubernetes

    A árvore de diretórios da API HTTP do Kubernetes pode ser dividida em três tipos de grupos independentes:

    1. Grupo Core (/api/v1) Este grupo inclui objetos como Pods, Services, Nodes, Namespaces, ConfigMaps, Secrets, etc.

    2. Grupo Nomeado Este grupo inclui objetos no formato /apis/$NAME/$VERSION. Estas diferentes versões da API implicam diferentes níveis de estabilidade e suporte:

      • Nível Alpha - pode ser removido a qualquer momento, sem aviso prévio. Por exemplo, /apis/batch/v2alpha1.
      • Nível Beta - é bem testado, mas a semântica dos objetos pode mudar de forma incompatível em uma versão beta ou estável subsequente. Por exemplo, /apis/certificates.k8s.io/v1beta1.
      • Nível Estável - aparece no software lançado por muitas versões subsequentes. Por exemplo, /apis/networking.k8s.io/v1.

    3. Sistema Amplo Este grupo consiste em endpoints de API de todo o sistema, como /healthz, /logs, /metrics, /ui, etc.

    Podemos acessar um Servidor API diretamente chamando os respectivos endpoints da API, usando as ferramentas CLI ou a Interface de Usuário do Dashboard.



kubectl​

O kubectl nos permite gerenciar clusters Kubernetes locais ou clusters remotos implantados na nuvem. Ele geralmente é instalado antes de instalar e iniciar o Minikube, mas também pode ser instalado após a etapa de inicialização do cluster.


Uma instalação do Minikube possui seu próprio cliente kubectl instalado e pronto para uso. No entanto, ele é um pouco inconveniente de usar, pois o comando kubectl se torna um subcomando do comando minikube. Os usuários teriam que digitar comandos mais longos, como minikube kubectl -- <subcommand> <object-type> <object-name> -o --option, em vez de apenas kubectl <subcommand> <object-type> <object-name> -o --option. Embora uma solução simples seja configurar um alias, a recomendação é executar a ferramenta CLI kubectl como uma instalação independente.


Uma vez instalado separadamente, kubectl recebe sua configuração automaticamente para acessar o cluster Kubernetes Minikube. No entanto, em diferentes configurações de clusters Kubernetes, pode ser necessário configurar manualmente os pontos de acesso ao cluster e os certificados exigidos pelo kubectl para acessar o cluster de forma segura.


Existem diferentes métodos que podem ser usados para instalar kubectl, listados na documentação do Kubernetes. Para obter os melhores resultados, é recomendado manter o kubectl dentro de uma versão secundária da versão desejada do Kubernetes.



Instalando o kubectl usando Curl​

Instale o binário kubectl no Linux usando o curl:


Terminal
# Baixe o binário do kubectl:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

# Instale o kubectl num diretório que faça parte do Path:
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

# Teste para garantir que a versão que você instalou esteja atualizada:
kubectl version --client

# Instale o pacote de auto-compleção:
$ sudo apt -y install bash-completion

# Adicione a auto-compleção do Minikube:
$ echo 'source <(minikube completion bash)' >> ~/.bashrc

# Recarregue o arquivo .bashrc:
$ source ~/.bashrc

# Se necessário, execute o comando abaixo:
minikube completion bash


kubectl Configuration File​

Para acessar o cluster Kubernetes, o cliente kubectl precisa do endpoint do node do Control Plane e das credenciais apropriadas para poder interagir com segurança com o Servidor API rodando no node do Control Plane. Ao iniciar o Minikube, o processo de inicialização cria, por padrão, um arquivo de configuração, config, dentro do diretório .kube (frequentemente referido como kubeconfig), que reside no diretório home do usuário. O arquivo de configuração contém todos os detalhes de conexão necessários para o kubectl.


Por padrão, o binário kubectl analisa este arquivo para encontrar o endpoint de conexão do node do Control Plane, juntamente com as credenciais necessárias. Vários arquivos kubeconfig podem ser configurados com um único cliente kubectl. Para ver os detalhes de conexão, podemos exibir o conteúdo do arquivo ~/.kube/config (no Linux) ou executar o seguinte comando (a saída é redigida para melhor legibilidade):


Terminal
$ kubectl config view

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /home/student/.minikube/ca.crt
    server: htt‌ps://192.168.99.100:8443
  name: minikube
contexts:
- context:
    cluster: minikube
    user: minikube
  name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
  user:
    client-certificate: /home/student/.minikube/profiles/minikube/client.crt
    client-key: /home/student/.minikube/profiles/minikube/client.key

O kubeconfig inclui o servidor de endpoint do servidor API: ht‌t‌ps://192.168.99.100:8443 e a chave de autenticação do cliente do usuário minikube e os dados do certificado. Depois que o kubectl estiver instalado, podemos exibir informações sobre o cluster Minikube Kubernetes com o comando kubectl cluster-info.


Embora para o cluster Kubernetes instalado pelo Minikube o arquivo ~/.kube/config seja criado automaticamente, este não é o caso dos clusters Kubernetes instalados por outras ferramentas. Em outros casos, o arquivo de configuração deve ser criado manualmente e, às vezes, reconfigurado para se adequar a diversas configurações de rede e cliente/servidor.



Kubernetes Dashboard​

O Painel Kubernetes fornece uma interface de usuário baseada na web para gerenciamento de cluster Kubernetes. O Minikube instala o Dashboard como um complemento, mas ele fica desabilitado por padrão. Antes de usar o Dashboard, somos obrigados a ativar o complemento Dashboard, junto com o complemento métricas-server, um complemento auxiliar projetado para coletar métricas de uso do cluster Kubernetes. Para acessar o painel do Minikube, podemos usar o comando minikube dashboard, que abre uma nova guia em nosso navegador exibindo o painel do Kubernetes, mas somente depois de listarmos, habilitarmos os complementos necessários e verificarmos seu estado:


Terminal
# Listar os complementos:
$ minikube addons list

# Habilita o complemento 'metrics-server':
$ minikube addons enable metrics-server

# Habilita o complemento 'dashboard':
$ minikube addons enable dashboard

# Acessar o dashboard:
$ minikube dashboard

Caso o navegador não esteja abrindo outra aba e não exiba o Dashboard conforme o esperado, verifique a saída em seu terminal, pois ele pode exibir uma URL para o Dashboard (junto com algumas mensagens de erro). Se a URL não for exibida, podemos solicitar que seja exibida com o seguinte comando:


Terminal
$ minikube dashboard --url


APIs with 'kubectl proxy'​

Ao emitir o comando kubectl proxy, o kubectl autentica-se com o servidor API no node do Control Plane e disponibiliza serviços na porta padrão do proxy, 8001. Primeiro, emitimos o comando kubectl proxy:


Terminal
$ kubectl proxy
Starting to serve on 127.0.0.1:8001

Ele bloqueia o terminal enquanto o proxy está em execução, a menos que o executemos em segundo plano (com kubectl proxy &). Quando o kubectl proxy está em execução, podemos enviar solicitações para a API no localhost na porta padrão do proxy 8001 (a partir de outro terminal, já que o proxy bloqueia o primeiro terminal quando executado em primeiro plano):


Terminal
$ curl http://localhost:8001/
{
 "paths": [
   "/api",
   "/api/v1",
   "/apis",
   "/apis/apps",
   ......
   ......
   "/logs",
   "/metrics",
   "/openapi/v2",
   "/version"
 ]
}

Com a solicitação curl acima, solicitamos todos os endpoints da API do servidor API. Clicando no link acima (no comando curl), ele abrirá a mesma lista de saída em uma aba do navegador. Podemos explorar várias combinações de caminhos com curl ou em um navegador, como:

http://localhost:8001/api/v1
http://localhost:8001/apis/apps/v1
http://localhost:8001/healthz
http://localhost:8001/metrics


APIs with Authentication​

Quando não estamos usando kubectl proxy, precisamos autenticar no servidor API ao enviar solicitações de API. Podemos autenticar fornecendo um Token de Portador (Bearer Token) ao emitir um comando curl, ou fornecendo um conjunto de chaves e certificados.


Um Token de Portador é um token de acesso que pode ser gerado pelo servidor de autenticação (o Servidor API no node do Control Plane) a pedido do cliente. Usando esse token, o cliente pode se comunicar com segurança com o Servidor API do Kubernetes sem fornecer detalhes adicionais de autenticação, e então acessar recursos. O token pode precisar ser fornecido novamente para solicitações de acesso a recursos subsequentes.


Vamos criar um token de acesso para a ServiceAccount padrão e conceder permissão especial para acessar o diretório raiz da API (permissão especial que não era necessária quando o kubectl proxy foi usado anteriormente). A permissão especial será definida por meio de uma política de Controle de Acesso Baseado em Função (RBAC). A política é o clusterrole definido abaixo, que é concedido por meio da definição de clusterrolebinding (RBAC, clusterroles e clusterrolebindings serão discutidos posteriormente). A permissão especial é necessária apenas para acessar o diretório raiz da API, mas não é necessária para acessar /api, /apis ou outros subdiretórios:


Terminal
$ export TOKEN=$(kubectl create token default)

$ kubectl create clusterrole api-access-root --verb=get --non-resource-url=/*

$ kubectl create clusterrolebinding api-access-root --clusterrole api-access-root --serviceaccount=default:default

Recuperar o endpoint do servidor API:

Terminal
$ export APISERVER=$(kubectl config view | grep https | cut -f 2- -d ":" | tr -d " ")

Confirmar se o APISERVER armazenou o mesmo IP que o IP do Control Plane do Kubernetes emitindo os dois comandos a seguir e comparando suas saídas:

Terminal
$ echo $APISERVER
https://192.168.99.100:8443

$ kubectl cluster-info
Kubernetes control plane is running at https://192.168.99.100:8443 ...

Acesse o Servidor API usando o comando curl, como mostrado abaixo:

Terminal
$ curl $APISERVER --header "Authorization: Bearer $TOKEN" --insecure

{
 "paths": [
   "/api",
   "/api/v1",
   "/apis",
   "/apis/apps",
   ......
   ......
   "/logs",
   "/metrics",
   "/openapi/v2",
   "/version"
 ]
}

Podemos executar comandos adicionais de curl para recuperar detalhes sobre grupos de API específicos da seguinte forma. Esses comandos devem funcionar mesmo sem a permissão especial definida acima e concedida à ServiceAccount padrão associada ao token de acesso:

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

$ curl $APISERVER/apis/apps/v1 --header "Authorization: Bearer $TOKEN" --insecure

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

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

Em vez do token de acesso, podemos extrair o certificado do cliente, a chave do cliente e os dados da autoridade de certificação do arquivo .kube/config. Uma vez extraídos, eles podem ser codificados e então passados com um comando curl para autenticação. O novo comando curl ficaria semelhante ao exemplo abaixo. No entanto, tenha em mente que o comando de exemplo abaixo só funcionaria com o certificado do cliente codificado em base64, chave e dados da autoridade de certificação, e é fornecido apenas para fins ilustrativos:

Terminal
$ curl $APISERVER --cert encoded-cert --key encoded-key --cacert encoded-ca

Terminal



Fontes​

https://minikube.sigs.k8s.io/docs/start/?arch=%2Flinux%2Fx86-64%2Fstable%2Fbinary+download