‫Para o seu primeiro cluster, talvez até os
‫primeiros, você não precisará se preocupar muito com
‫esse conceito de namespaces e contextos.
‫Mas, é algo que você precisa
‫estar ciente de que existe, caso precise usá-lo.
‫Namespaces são essencialmente clusters virtuais, ou visualizações virtuais,
‫dentro de um único cluster.
‫Ele filtra não apenas a exibição do comando, para que você
‫veja apenas algumas coisas ao digitar comandos,
‫mas também, com os plug-ins de diretiva de rede
‫corretos, pode controlar a rede.
‫Isso é um pouco diferente do Swarm, onde o
‫Swarm, pronto para uso, você cria redes de sobreposição diferentes
‫e tudo é essencialmente privado.
‫No Kubernetes, a conexão em rede e o controle de aplicativos e
‫sua privacidade, o que eles podem ver e acessar, e
‫o que é fisicamente controlado lá, é realmente dependente do seu
‫plug-in de rede.
‫Os namespaces em si não estão relacionados aos namespaces do Docker,
‫dos quais você já deve ter ouvido falar, que realmente
‫faz parte do subsistema Linux, e é assim que
‫os contêineres funcionam. Isso não tem nada a ver com isso.
‫Isso é simplesmente o Kubernetes dizendo: ei, você pode ter um
‫monte de coisas acontecendo no seu cluster, e eu estou lhe
‫dando a oportunidade de criar pequenos mini-clusters nos quais
‫você definiria o namespace com um contexto e essa
‫é a sua visão. mudando seu contexto.
‫Você pode mudar o que vê.
‫Em seguida, o espaço para nome é segmentos
‫diferentes para filtrar os comandos, bem como potencialmente
‫a rede. No meu sistema aqui na
‫área de trabalho, simplesmente vejo o kubectl obter namespaces e esse
‫comando me mostra 4. Esse é o padrão
‫que você vai ver, pronto para uso.
‫O padrão é o que você tem trabalhado até agora.
‫Feito para o espaço de nome padrão dos
‫seus aplicativos. A única coisa que realmente
‫mostra quando você faz um kubectl obter
‫tudo é o próprio ponto de extremidade da API do Kubernetes, certo.
‫Até começarmos a adicionar aplicativos, não vimos
‫nada lá. Tecnicamente, tudo isso
‫funciona em segundo plano, certo. É isso que o kubectl obtém todos
‫- todos os namespaces.
‫Você pode ver todos os contêineres da API
‫e outros enfeites em execução no próprio Kubernetes
‫com esse comando. Se eu olhar para todos os espaços para nome
‫de uma só vez, recebo tudo, incluindo as coisas do sistema.
‫Esta é uma visão de como seria no
‫minikube, que coloca tudo em seus próprios pods para executar
‫o próprio cluster.
‫Há muita coisa acontecendo lá.
‫A conclusão é que, quando você normalmente usa
‫o Kubernetes, a linha de comando se concentra no espaço para
‫nome padrão, por padrão.
‫Você realmente verá apenas seus aplicativos lá, além do ponto
‫de extremidade da API.
‫Isso é bom, certo. Ele oculta a
‫complexidade do que está acontecendo em segundo plano
‫a partir do seu comando diário, porque você
‫realmente não precisa ver essas coisas, a menos que precise atualizá-las, alterá-las
‫ou se tiver algum problema. O contexto entra em
‫jogo para definir sua exibição quando você estiver executando comandos.
‫O kubectl faz muitas coisas, certo.
‫Ele pode se conectar a diferentes clusters.
‫Pode alterar a autenticação, ou o usuário, que você
‫está usando para conversar com o cluster, sobre o qual
‫não falamos, ou o espaço para nome.
‫Então, existem essas três partes, realmente, de um contexto.
‫Esse é o cluster, a autenticação ou o usuário e, em seguida,
‫o espaço para nome que você deseja ver.
‫Tudo o que é definido, por padrão, em
‫um arquivo dentro do. diretório kube do seu
‫diretório inicial.
‫Existe um arquivo chamado config,
‫e será basicamente um arquivo YAML, três dessas partes.
‫Você pode ter várias entradas lá e pode
‫editá-lo como quiser.
‫Você pode ter vários clusters diferentes e, desde que possua os certificados
‫para conversar com eles, a autenticação correta, você pode colocar
‫todo esse material nesse arquivo e é algo que você deseja
‫manter em segredo. Não é
‫algo que você realmente deseja compartilhar, porque normalmente
‫possui suas chaves de autenticação para
‫conversar com um cluster. Se você usar
‫o comando kubectl config com o subcomando de contextos get, isso
‫é plural, você poderá ver basicamente
‫a saída desse arquivo. Em vez de
‫despejá-lo bruto, você pode realmente ver uma
‫pequena lista do que ele contém.
‫No meu caso, tenho meu Docker Desktop padrão na
‫minha máquina local. Essa entrada aparece duas
‫vezes nas últimas edições do Docker Desktop porque eles mudaram o
‫nome e, portanto, mantêm os dois lá por compatibilidade.
‫Então eu tenho um minikube local e
‫uma instância remota de micro K8s executando em
‫um servidor Ubuntu.
‫Então, você pode imaginar que, se eu
‫estava gerenciando muitos outros servidores, nem sempre eu quero
‫ssh nessas máquinas. Eu realmente só quero sentar na minha máquina local
‫e conversar com essa API remota.
‫Você pode usar o comando kubectl config com qualquer
‫uma das opções definidas. Você definitivamente deseja
‫verificar a ajuda lá. Porém, existem opções definidas para
‫definir os padrões para cada um deles, para
‫que você possa alterar o usuário para
‫ter uma autenticação diferente. Portanto, talvez você tenha direitos
‫de Deus, em vez de apenas um subconjunto dos comandos que o
‫Kubernetes está executando. Ou talvez você mude o cluster
‫com o qual está falando.
‫Existem até plugins de linha de comando, se você
‫procurar no Google por permitir ver
‫em seu shell qual o contexto que você está usando.
‫Isso é bastante útil quando você acaba gerenciando um monte
‫de clusters diferentes. Você quer saber,
‫ei com quem estou falando agora? Na verdade, você pode configurá-lo,
‫como, por exemplo, como os prompts de recebimento informarão em
‫que ramo você está. Isso informará, em seu prompt,
‫qual contexto você possui.