Kubernetes - Guia rápido

Kubernetes em uma ferramenta de gerenciamento de contêiner de código aberto hospedada pela Cloud Native Computing Foundation (CNCF). Isso também é conhecido como a versão aprimorada do Borg que foi desenvolvida no Google para gerenciar processos de longa execução e trabalhos em lote, que antes eram tratados por sistemas separados.

O Kubernetes vem com um recurso de implantação automatizada, escalonamento de aplicativo e operações de contêineres de aplicativo em clusters. Ele é capaz de criar uma infraestrutura centrada em contêiner.

Recursos do Kubernetes

A seguir estão alguns dos recursos importantes do Kubernetes.

• Desenvolvimento contínuo, integração e implantação

• Infraestrutura em contêineres

• Gerenciamento centrado em aplicativos

• Infraestrutura autoescalável

• Consistência do ambiente em testes de desenvolvimento e produção

• Infraestrutura fracamente acoplada, onde cada componente pode atuar como uma unidade separada

• Maior densidade de utilização de recursos

• Infraestrutura previsível que será criada

Um dos principais componentes do Kubernetes é que ele pode executar aplicativos em clusters de infraestrutura de máquina física e virtual. Ele também tem a capacidade de executar aplicativos na nuvem.It helps in moving from host-centric infrastructure to container-centric infrastructure.

Neste capítulo, discutiremos a arquitetura básica do Kubernetes.

Kubernetes - Arquitetura de Cluster

Conforme visto no diagrama a seguir, o Kubernetes segue a arquitetura cliente-servidor. Onde, temos o master instalado em uma máquina e o nó em máquinas Linux separadas.

Os principais componentes do mestre e do nó são definidos na seção a seguir.

Kubernetes - componentes da máquina mestre

A seguir estão os componentes da máquina mestre do Kubernetes.

etcd

Ele armazena as informações de configuração que podem ser usadas por cada um dos nós do cluster. É um armazenamento de valor de chave de alta disponibilidade que pode ser distribuído entre vários nós. Ele pode ser acessado apenas pelo servidor da API Kubernetes, pois pode conter algumas informações confidenciais. É uma Loja de valores-chave distribuída acessível a todos.

Servidor API

Kubernetes é um servidor de API que fornece todas as operações no cluster usando a API. O servidor API implementa uma interface, o que significa que diferentes ferramentas e bibliotecas podem se comunicar prontamente com ele.Kubeconfigé um pacote junto com as ferramentas do lado do servidor que podem ser usadas para comunicação. Ele expõe a API Kubernetes.

Gerente de Controlador

Este componente é responsável pela maioria dos coletores que regula o estado do cluster e executa uma tarefa. Em geral, ele pode ser considerado um daemon que é executado em loop não terminal e é responsável por coletar e enviar informações ao servidor API. Ele trabalha para obter o estado compartilhado do cluster e, em seguida, faz alterações para trazer o status atual do servidor para o estado desejado. Os controladores principais são controlador de replicação, controlador de terminal, controlador de namespace e controlador de conta de serviço. O gerenciador de controlador executa diferentes tipos de controladores para lidar com nós, terminais, etc.

Agendador

Este é um dos principais componentes do mestre Kubernetes. É um serviço em mestre responsável por distribuir a carga de trabalho. Ele é responsável por rastrear a utilização da carga de trabalho nos nós do cluster e, em seguida, colocar a carga de trabalho na qual os recursos estão disponíveis e aceitar a carga de trabalho. Em outras palavras, esse é o mecanismo responsável por alocar pods aos nós disponíveis. O planejador é responsável pela utilização da carga de trabalho e alocação do pod para o novo nó.

Kubernetes - componentes do nó

A seguir estão os principais componentes do servidor Node, que são necessários para se comunicar com o mestre Kubernetes.

Docker

O primeiro requisito de cada nó é o Docker, que ajuda a executar os contêineres de aplicativos encapsulados em um ambiente operacional relativamente isolado, mas leve.

Serviço Kubelet

Este é um pequeno serviço em cada nó responsável por retransmitir informações de e para o serviço do plano de controle. Interage cometcdstore para ler detalhes de configuração e valores corretos. Este se comunica com o componente mestre para receber comandos e trabalhar. okubeleto processo então assume a responsabilidade por manter o estado de trabalho e o servidor do nó. Ele gerencia regras de rede, encaminhamento de porta, etc.

Serviço Kubernetes Proxy

Este é um serviço de proxy que roda em cada nó e ajuda a disponibilizar serviços para o host externo. Ele ajuda a encaminhar a solicitação para contêineres corretos e é capaz de realizar balanceamento de carga primitivo. Ele garante que o ambiente de rede seja previsível e acessível e, ao mesmo tempo, isolado. Ele gerencia pods em nós, volumes, segredos, criando verificação de integridade de novos contêineres etc.

Kubernetes - Estrutura mestre e de nós

As ilustrações a seguir mostram a estrutura do mestre e do nó do Kubernetes.

É importante configurar o Virtual Datacenter (vDC) antes de configurar o Kubernetes. Isso pode ser considerado um conjunto de máquinas onde podem se comunicar entre si através da rede. Para uma abordagem prática, você pode configurar o vDC onPROFITBRICKS se você não tiver uma infraestrutura física ou em nuvem configurada.

Assim que a configuração de IaaS em qualquer nuvem for concluída, você precisa configurar o Master e a Node.

Note- A configuração é mostrada para máquinas Ubuntu. O mesmo pode ser configurado em outras máquinas Linux também.

Pré-requisitos

Installing Docker- O Docker é necessário em todas as instâncias do Kubernetes. A seguir estão as etapas para instalar o Docker.

Step 1 - Faça logon na máquina com a conta de usuário root.

Step 2- Atualize as informações do pacote. Certifique-se de que o pacote apt está funcionando.

Step 3 - Execute os seguintes comandos.

$ sudo apt-get update $ sudo apt-get install apt-transport-https ca-certificates

Step 4 - Adicione a nova chave GPG.

$ sudo apt-key adv \ --keyserver hkp://ha.pool.sks-keyservers.net:80 \ --recv-keys 58118E89F3A912897C070ADBF76221572C52609D $ echo "deb https://apt.dockerproject.org/repo ubuntu-trusty main" | sudo tee
/etc/apt/sources.list.d/docker.list

Step 5 - Atualize a imagem do pacote de API.

$ sudo apt-get update

Depois que todas as tarefas acima forem concluídas, você pode começar com a instalação real do mecanismo Docker. No entanto, antes disso, você precisa verificar se a versão do kernel que está usando está correta.

Instale o Docker Engine

Execute os comandos a seguir para instalar o mecanismo Docker.

Step 1 - Faça logon na máquina.

Step 2 - Atualize o índice do pacote.

$ sudo apt-get update

Step 3 - Instale o Docker Engine usando o seguinte comando.

$ sudo apt-get install docker-engine

Step 4 - Inicie o daemon Docker.

$ sudo apt-get install docker-engine

Step 5 - Para saber se o Docker está instalado, use o seguinte comando.

$ sudo docker run hello-world

Instale o etcd 2.0

Isso precisa ser instalado na máquina mestre do Kubernetes. Para instalá-lo, execute os seguintes comandos.

$ curl -L https://github.com/coreos/etcd/releases/download/v2.0.0/etcd
-v2.0.0-linux-amd64.tar.gz -o etcd-v2.0.0-linux-amd64.tar.gz ->1
$ tar xzvf etcd-v2.0.0-linux-amd64.tar.gz ------>2 $ cd etcd-v2.0.0-linux-amd64 ------------>3
$ mkdir /opt/bin ------------->4 $ cp etcd* /opt/bin ----------->5

No conjunto de comandos acima -

• Primeiro, baixamos o etcd. Salve isso com o nome especificado.
• Então, temos que descompactar o pacote tar.
• Nós fazemos um dir. dentro do bin nomeado / opt.
• Copie o arquivo extraído para o local de destino.

Agora estamos prontos para construir o Kubernetes. Precisamos instalar o Kubernetes em todas as máquinas do cluster.

$ git clone https://github.com/GoogleCloudPlatform/kubernetes.git $ cd kubernetes
$ make release

O comando acima irá criar um _outputdir na raiz da pasta kubernetes. Em seguida, podemos extrair o diretório em qualquer diretório de nossa escolha / opt / bin, etc.

Em seguida, vem a parte da rede em que precisamos realmente começar com a configuração do mestre e do nó do Kubernetes. Para fazer isso, faremos uma entrada no arquivo host que pode ser feito na máquina do nó.

$ echo "<IP address of master machine> kube-master
< IP address of Node Machine>" >> /etc/hosts

A seguir será a saída do comando acima.

Agora, começaremos com a configuração real no Kubernetes Master.

Primeiro, vamos começar a copiar todos os arquivos de configuração para seus locais corretos.

$ cp <Current dir. location>/kube-apiserver /opt/bin/ $ cp <Current dir. location>/kube-controller-manager /opt/bin/
$ cp <Current dir. location>/kube-kube-scheduler /opt/bin/ $ cp <Current dir. location>/kubecfg /opt/bin/
$ cp <Current dir. location>/kubectl /opt/bin/ $ cp <Current dir. location>/kubernetes /opt/bin/

O comando acima irá copiar todos os arquivos de configuração para o local necessário. Agora voltaremos ao mesmo diretório em que criamos a pasta Kubernetes.

$ cp kubernetes/cluster/ubuntu/init_conf/kube-apiserver.conf /etc/init/ $ cp kubernetes/cluster/ubuntu/init_conf/kube-controller-manager.conf /etc/init/
$ cp kubernetes/cluster/ubuntu/init_conf/kube-kube-scheduler.conf /etc/init/ $ cp kubernetes/cluster/ubuntu/initd_scripts/kube-apiserver /etc/init.d/
$ cp kubernetes/cluster/ubuntu/initd_scripts/kube-controller-manager /etc/init.d/ $ cp kubernetes/cluster/ubuntu/initd_scripts/kube-kube-scheduler /etc/init.d/

$ cp kubernetes/cluster/ubuntu/default_scripts/kubelet /etc/default/ $ cp kubernetes/cluster/ubuntu/default_scripts/kube-proxy /etc/default/
$ cp kubernetes/cluster/ubuntu/default_scripts/kubelet /etc/default/

A próxima etapa é atualizar o arquivo de configuração copiado em / etc. dir.

Configure o etcd no master usando o seguinte comando.

$ ETCD_OPTS = "-listen-client-urls = http://kube-master:4001"

Configurar kube-apiserver

Para isso no mestre, precisamos editar o /etc/default/kube-apiserver arquivo que copiamos anteriormente.

$ KUBE_APISERVER_OPTS = "--address = 0.0.0.0 \
--port = 8080 \
--etcd_servers = <The path that is configured in ETCD_OPTS> \
--portal_net = 11.1.1.0/24 \
--allow_privileged = false \
--kubelet_port = < Port you want to configure> \
--v = 0"

Configure o gerenciador de controle kube

Precisamos adicionar o seguinte conteúdo em /etc/default/kube-controller-manager.

$ KUBE_CONTROLLER_MANAGER_OPTS = "--address = 0.0.0.0 \
--master = 127.0.0.1:8080 \
--machines = kube-minion \ -----> #this is the kubernatics node
--v = 0

Em seguida, configure o agendador kube no arquivo correspondente.

$ KUBE_SCHEDULER_OPTS = "--address = 0.0.0.0 \
--master = 127.0.0.1:8080 \
--v = 0"

Depois que todas as tarefas acima forem concluídas, podemos prosseguir, trazendo o Kubernetes Master. Para fazer isso, reiniciaremos o Docker.

$ service docker restart

Configuração de nó do Kubernetes

O nó do Kubernetes executará dois serviços, kubelet and the kube-proxy. Antes de prosseguir, precisamos copiar os binários baixados para suas pastas necessárias, onde queremos configurar o nó do kubernetes.

Use o mesmo método de copiar os arquivos que fizemos para o mestre do kubernetes. Como ele só executará o kubelet e o kube-proxy, iremos configurá-los.

$ cp <Path of the extracted file>/kubelet /opt/bin/ $ cp <Path of the extracted file>/kube-proxy /opt/bin/
$ cp <Path of the extracted file>/kubecfg /opt/bin/ $ cp <Path of the extracted file>/kubectl /opt/bin/
$ cp <Path of the extracted file>/kubernetes /opt/bin/

Agora, vamos copiar o conteúdo para o diretório apropriado.

$ cp kubernetes/cluster/ubuntu/init_conf/kubelet.conf /etc/init/
$ cp kubernetes/cluster/ubuntu/init_conf/kube-proxy.conf /etc/init/ $ cp kubernetes/cluster/ubuntu/initd_scripts/kubelet /etc/init.d/
$ cp kubernetes/cluster/ubuntu/initd_scripts/kube-proxy /etc/init.d/ $ cp kubernetes/cluster/ubuntu/default_scripts/kubelet /etc/default/
$ cp kubernetes/cluster/ubuntu/default_scripts/kube-proxy /etc/default/

Vamos configurar o kubelet e kube-proxy conf arquivos.

Vamos configurar o /etc/init/kubelet.conf.

$ KUBELET_OPTS = "--address = 0.0.0.0 \
--port = 10250 \
--hostname_override = kube-minion \
--etcd_servers = http://kube-master:4001 \
--enable_server = true
--v = 0"
/

Para kube-proxy, iremos configurar usando o seguinte comando.

$ KUBE_PROXY_OPTS = "--etcd_servers = http://kube-master:4001 \
--v = 0"
/etc/init/kube-proxy.conf

Por fim, reiniciaremos o serviço Docker.

$ service docker restart

Agora terminamos a configuração. Você pode verificar executando os seguintes comandos.

$ /opt/bin/kubectl get minions

As imagens do Kubernetes (Docker) são os principais blocos de construção da infraestrutura em contêiner. Por enquanto, oferecemos suporte apenas ao Kubernetes para oferecer suporte a imagens do Docker. Cada contêiner em um pod tem sua imagem Docker em execução dentro dele.

Quando estamos configurando um pod, a propriedade da imagem no arquivo de configuração tem a mesma sintaxe que o comando Docker. O arquivo de configuração possui um campo para definir o nome da imagem, que planejamos extrair do registro.

A seguir está a estrutura de configuração comum que extrairá a imagem do registro do Docker e implantará no contêiner do Kubernetes.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> 1
   spec:
      containers:
         - name: neo4j-server ------------------------> 2
         image: <Name of the Docker image>----------> 3
         imagePullPolicy: Always ------------->4
         command: ["echo", "SUCCESS"] ------------------->

No código acima, definimos -

• name: Tesing_for_Image_pull - Este nome é fornecido para identificar e verificar qual é o nome do contêiner que seria criado após obter as imagens do registro do Docker.

• name: neo4j-server- Este é o nome dado ao container que estamos tentando criar. Como demos o neo4j-server.

• image: <Name of the Docker image>- Este é o nome da imagem que estamos tentando extrair do Docker ou do registro interno de imagens. Precisamos definir um caminho de registro completo junto com o nome da imagem que estamos tentando obter.

• imagePullPolicy - Sempre - esta política de extração de imagem define que sempre que executarmos esse arquivo para criar o contêiner, ele obterá o mesmo nome novamente.

• command: [“echo”, “SUCCESS”] - Com isso, ao criarmos o container e se tudo correr bem, será exibida uma mensagem quando acessarmos o container.

Para extrair a imagem e criar um contêiner, executaremos o seguinte comando.

$ kubectl create –f Tesing_for_Image_pull

Assim que buscarmos o log, obteremos a saída como bem-sucedida.

$ kubectl log Tesing_for_Image_pull

O comando acima produzirá uma saída de sucesso ou obteremos uma saída como falha.

Note - Recomenda-se que você tente todos os comandos sozinho.

A principal função de um trabalho é criar um ou mais pods e rastrear o sucesso dos pods. Eles garantem que o número especificado de pods seja concluído com êxito. Quando um número especificado de execuções bem-sucedidas de pods é concluído, o trabalho é considerado concluído.

Criando um Trabalho

Use o seguinte comando para criar um trabalho -

apiVersion: v1
kind: Job ------------------------> 1
metadata:
   name: py
   spec:
   template:
      metadata
      name: py -------> 2
      spec:
         containers:
            - name: py ------------------------> 3
            image: python----------> 4
            command: ["python", "SUCCESS"]
            restartPocliy: Never --------> 5

No código acima, definimos -

• kind: Job → Nós definimos o tipo de Jó que dirá kubectl que o yaml arquivo sendo usado é para criar um pod de tipo de trabalho.

• Name:py → Este é o nome do modelo que estamos usando e a especificação define o modelo.

• name: py → demos um nome como py sob as especificações do contêiner, o que ajuda a identificar o pod que será criado a partir dele.

• Image: python → a imagem que vamos extrair para criar o contêiner que será executado dentro do pod.

• restartPolicy: Never →Esta condição de reinicialização da imagem é dada como nunca, o que significa que se o contêiner for eliminado ou se for falso, ele não reiniciará sozinho.

Iremos criar o trabalho usando o seguinte comando com yaml que é salvo com o nome py.yaml.

$ kubectl create –f py.yaml

O comando acima irá criar um trabalho. Se você deseja verificar o status de um trabalho, use o seguinte comando.

$ kubectl describe jobs/py

O comando acima irá criar um trabalho. Se você deseja verificar o status de um trabalho, use o seguinte comando.

Trabalho Programado

Trabalho agendado em Kubernetes usa Cronetes, que pega o job do Kubernetes e os inicia no cluster do Kubernetes.

• A programação de um trabalho executará um pod em um determinado momento.
• Um trabalho paródico é criado para ele, que se invoca automaticamente.

Note - O recurso de um trabalho agendado é suportado pela versão 1.4 e a API betch / v2alpha 1 é ativada passando o –runtime-config=batch/v2alpha1 ao abrir o servidor API.

Usaremos o mesmo yaml que usamos para criar o trabalho e torná-lo um trabalho agendado.

apiVersion: v1
kind: Job
metadata:
   name: py
spec:
   schedule: h/30 * * * * ? -------------------> 1
   template:
      metadata
         name: py
      spec:
         containers:
         - name: py
         image: python
         args:
/bin/sh -------> 2
-c
ps –eaf ------------> 3
restartPocliy: OnFailure

No código acima, definimos -

• schedule: h/30 * * * * ? → Para agendar o trabalho para ser executado a cada 30 minutos.

• /bin/sh: Isso vai entrar no contêiner com / bin / sh

• ps –eaf → Irá executar o comando ps -eaf na máquina e listar todos os processos em execução dentro de um contêiner.

Este conceito de trabalho agendado é útil quando estamos tentando construir e executar um conjunto de tarefas em um determinado momento e, em seguida, concluir o processo.

Etiquetas

Os rótulos são pares de chave-valor anexados a pods, controlador de replicação e serviços. Eles são usados ​​como atributos de identificação para objetos como pods e controlador de replicação. Eles podem ser adicionados a um objeto no momento da criação e podem ser adicionados ou modificados no tempo de execução.

Seletores

As etiquetas não fornecem exclusividade. Em geral, podemos dizer que muitos objetos podem carregar os mesmos rótulos. O seletor de rótulos é primitivo de agrupamento principal no Kubernetes. Eles são usados ​​pelos usuários para selecionar um conjunto de objetos.

A API Kubernetes atualmente oferece suporte a dois tipos de seletores -

• Seletores baseados em igualdade
• Seletores baseados em conjuntos

Seletores com base na igualdade

Eles permitem a filtragem por chave e valor. Os objetos correspondentes devem satisfazer todos os rótulos especificados.

Seletores baseados em conjuntos

Os seletores baseados em conjunto permitem a filtragem de chaves de acordo com um conjunto de valores.

apiVersion: v1
kind: Service
metadata:
   name: sp-neo4j-standalone
spec:
   ports:
      - port: 7474
      name: neo4j
   type: NodePort
   selector:
      app: salesplatform ---------> 1
      component: neo4j -----------> 2

No código acima, estamos usando o seletor de rótulos como app: salesplatform e componente como component: neo4j.

Depois de executar o arquivo usando o kubectl comando, ele irá criar um serviço com o nome sp-neo4j-standalone que se comunicará na porta 7474. O ype é NodePort com o novo seletor de rótulo como app: salesplatform e component: neo4j.

O namespace fornece uma qualificação adicional para um nome de recurso. Isso é útil quando várias equipes estão usando o mesmo cluster e há um potencial de colisão de nomes. Pode ser como uma parede virtual entre vários clusters.

Funcionalidade do namespace

A seguir estão algumas das funcionalidades importantes de um namespace no Kubernetes -

• Os namespaces ajudam na comunicação pod-a-pod usando o mesmo namespace.

• Os namespaces são clusters virtuais que podem ficar no topo do mesmo cluster físico.

• Eles fornecem separação lógica entre as equipes e seus ambientes.

Crie um namespace

O seguinte comando é usado para criar um namespace.

apiVersion: v1
kind: Namespce
metadata
   name: elk

Controle o namespace

O comando a seguir é usado para controlar o namespace.

$ kubectl create –f namespace.yml ---------> 1
$ kubectl get namespace -----------------> 2 $ kubectl get namespace <Namespace name> ------->3
$ kubectl describe namespace <Namespace name> ---->4 $ kubectl delete namespace <Namespace name>

No código acima,

• Estamos usando o comando para criar um namespace.
• Isso listará todos os namespaces disponíveis.
• Isso obterá um namespace específico cujo nome é especificado no comando.
• Isso descreverá os detalhes completos sobre o serviço.
• Isso excluirá um determinado namespace presente no cluster.

Usando Namespace no Serviço - Exemplo

A seguir está um exemplo de um arquivo de amostra para usar o namespace no serviço.

apiVersion: v1
kind: Service
metadata:
   name: elasticsearch
   namespace: elk
   labels:
      component: elasticsearch
spec:
   type: LoadBalancer
   selector:
      component: elasticsearch
   ports:
   - name: http
      port: 9200
      protocol: TCP
   - name: transport
      port: 9300
      protocol: TCP

No código acima, estamos usando o mesmo namespace nos metadados de serviço com o nome de elk.

Um nó é uma máquina em funcionamento no cluster do Kubernetes, também conhecido como lacaio. Eles são unidades de trabalho que podem ser físicas, VM ou uma instância de nuvem.

Cada nó tem toda a configuração necessária para executar um pod nele, como o serviço de proxy e o serviço kubelet junto com o Docker, que é usado para executar os contêineres do Docker no pod criado no nó.

Eles não são criados pelo Kubernetes, mas são criados externamente pelo provedor de serviços de nuvem ou pelo gerenciador de cluster Kubernetes em máquinas físicas ou VM.

O principal componente do Kubernetes para lidar com vários nós é o gerenciador de controladores, que executa vários tipos de controladores para gerenciar nós. Para gerenciar nós, o Kubernetes cria um objeto do tipo nó que validará se o objeto criado é um nó válido.

Serviço com Seletor

apiVersion: v1
kind: node
metadata:
   name: < ip address of the node>
   labels:
      name: <lable name>

No formato JSON, o objeto real é criado e se parece com o seguinte -

{
   Kind: node
   apiVersion: v1
   "metadata": 
   {
      "name": "10.01.1.10",
      "labels"
      {
         "name": "cluster 1 node"
      }
   }
}

Controlador de Nó

Eles são a coleção de serviços executados no mestre do Kubernetes e monitoram continuamente o nó no cluster com base em metadata.name. Se todos os serviços necessários estiverem em execução, o nó será validado e um pod recém-criado será atribuído a esse nó pelo controlador. Se não for válido, o mestre não atribuirá nenhum pod a ele e esperará até que ele se torne válido.

O mestre do Kubernetes registra o nó automaticamente, se –register-node bandeira é verdade.

–register-node = true

No entanto, se o administrador do cluster quiser gerenciá-lo manualmente, isso pode ser feito girando o botão de -

–register-node = false

Um serviço pode ser definido como um conjunto lógico de pods. Ele pode ser definido como uma abstração na parte superior do pod, que fornece um único endereço IP e nome DNS pelo qual os pods podem ser acessados. Com o Service, é muito fácil gerenciar a configuração de balanceamento de carga. Isso ajuda a escalar os pods com muita facilidade.

Um serviço é um objeto REST no Kubernetes, cuja definição pode ser postada no Kubernetes apiServer no mestre do Kubernetes para criar uma nova instância.

Serviço sem seletor

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
   - port: 8080
   targetPort: 31999

A configuração acima criará um serviço com o nome Tutorial_point_service.

Arquivo de configuração de serviço com seletor

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   selector:
      application: "My Application" -------------------> (Selector)
   ports:
   - port: 8080
   targetPort: 31999

Neste exemplo, temos um seletor; então, para transferir o tráfego, precisamos criar um endpoint manualmente.

apiVersion: v1
kind: Endpoints
metadata:
   name: Tutorial_point_service
subnets:
   address:
      "ip": "192.168.168.40" -------------------> (Selector)
   ports:
      - port: 8080

No código acima, criamos um endpoint que roteará o tráfego para o endpoint definido como “192.168.168.40:8080”.

Criação de serviço multiporta

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   selector:
      application: “My Application” -------------------> (Selector)
   ClusterIP: 10.3.0.12
   ports:
      -name: http
      protocol: TCP
      port: 80
      targetPort: 31999
   -name:https
      Protocol: TCP
      Port: 443
      targetPort: 31998

Tipos de serviços

ClusterIP- Isso ajuda a restringir o serviço dentro do cluster. Ele expõe o serviço dentro do cluster Kubernetes definido.

spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: NodeportService

NodePort- Exporá o serviço em uma porta estática no nó implantado. UMAClusterIP serviço, para o qual NodePortserviço irá rotear, é criado automaticamente. O serviço pode ser acessado de fora do cluster usando oNodeIP:nodePort.

spec:
   ports:
   - port: 8080
      nodePort: 31999
      name: NodeportService
      clusterIP: 10.20.30.40

Load Balancer - Ele usa o balanceador de carga dos provedores de nuvem. NodePort e ClusterIP serviços são criados automaticamente para os quais o balanceador de carga externo irá rotear.

Um serviço completo yamlarquivo com tipo de serviço como Node Port. Tente criar um você mesmo.

apiVersion: v1
kind: Service
metadata:
   name: appname
   labels:
      k8s-app: appname
spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: omninginx
   selector:
      k8s-app: appname
      component: nginx
      env: env_name

Um pod é uma coleção de contêineres e seu armazenamento dentro de um nó de um cluster do Kubernetes. É possível criar um pod com vários contêineres dentro dele. Por exemplo, manter um contêiner de banco de dados e um contêiner de dados no mesmo pod.

Tipos de pod

Existem dois tipos de pods -

• Pod de recipiente único
• Multi container pod

Pod de contêiner único

Eles podem ser simplesmente criados com o comando kubctl run, onde você tem uma imagem definida no registro do Docker que extrairemos ao criar um pod.

$ kubectl run <name of pod> --image=<name of the image from registry>

Example - Criaremos um pod com uma imagem tomcat que está disponível no hub Docker.

$ kubectl run tomcat --image = tomcat:8.0

Isso também pode ser feito criando o yaml arquivo e, em seguida, executar o kubectl create comando.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
    image: tomcat: 8.0
    ports:
containerPort: 7500
   imagePullPolicy: Always

Uma vez que o acima yaml arquivo for criado, vamos salvar o arquivo com o nome de tomcat.yml e execute o comando create para executar o documento.

$ kubectl create –f tomcat.yml

Ele criará um pod com o nome de tomcat. Podemos usar o comando describe junto comkubectl para descrever o pod.

Multi Container Pod

Os pods de vários contêineres são criados usando yaml mail com a definição dos containers.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
    image: tomcat: 8.0
    ports:
containerPort: 7500
   imagePullPolicy: Always
   -name: Database
   Image: mongoDB
   Ports:
containerPort: 7501
   imagePullPolicy: Always

No código acima, criamos um pod com dois contêineres dentro dele, um para tomcat e outro para MongoDB.

O controlador de replicação é um dos principais recursos do Kubernetes, responsável por gerenciar o ciclo de vida do pod. Ele é responsável por garantir que o número especificado de réplicas de pod estejam em execução a qualquer momento. É usado quando se deseja ter certeza de que o número especificado de pod ou pelo menos um pod está em execução. Ele tem a capacidade de aumentar ou diminuir o número especificado de pod.

É uma prática recomendada usar o controlador de replicação para gerenciar o ciclo de vida do pod, em vez de criar um pod repetidamente.

apiVersion: v1
kind: ReplicationController --------------------------> 1
metadata:
   name: Tomcat-ReplicationController --------------------------> 2
spec:
   replicas: 3 ------------------------> 3
   template:
      metadata:
         name: Tomcat-ReplicationController
      labels:
         app: App
         component: neo4j
      spec:
         containers:
         - name: Tomcat- -----------------------> 4
         image: tomcat: 8.0
         ports:
            - containerPort: 7474 ------------------------> 5

Detalhes de configuração

• Kind: ReplicationController → No código acima, definimos o tipo como controlador de replicação que informa ao kubectl que o yaml será usado para criar o controlador de replicação.

• name: Tomcat-ReplicationController→ Isso ajuda a identificar o nome com o qual o controlador de replicação será criado. Se executarmos o kubctl, obtenharc < Tomcat-ReplicationController > ele mostrará os detalhes do controlador de replicação.

• replicas: 3 → Isso ajuda o controlador de replicação a entender que precisa manter três réplicas de um pod em qualquer ponto do tempo do ciclo de vida do pod.

• name: Tomcat → Na seção de especificações, definimos o nome como tomcat, que dirá ao controlador de replicação que o contêiner presente dentro dos pods é tomcat.

• containerPort: 7474 → Isso ajuda a garantir que todos os nós no cluster em que o pod está executando o contêiner dentro do pod sejam expostos na mesma porta 7474.

Aqui, o serviço Kubernetes está funcionando como um balanceador de carga para três réplicas do Tomcat.

O conjunto de réplicas garante quantas réplicas de pod devem estar em execução. Pode ser considerado uma substituição do controlador de replicação. A principal diferença entre o conjunto de réplicas e o controlador de replicação é que o controlador de replicação só oferece suporte ao seletor baseado em igualdade, enquanto o conjunto de réplicas oferece suporte ao seletor baseado em conjunto.

apiVersion: extensions/v1beta1 --------------------->1
kind: ReplicaSet --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   selector:
      matchLables:
         tier: Backend ------------------> 3
      matchExpression:
{ key: tier, operation: In, values: [Backend]} --------------> 4
template:
   metadata:
      lables:
         app: Tomcat-ReplicaSet
         tier: Backend
      labels:
         app: App
         component: neo4j
   spec:
      containers:
      - name: Tomcat
      image: tomcat: 8.0
      ports:
      - containerPort: 7474

Detalhes de configuração

• apiVersion: extensions/v1beta1 → No código acima, a versão da API é a versão beta avançada do Kubernetes, que oferece suporte ao conceito de conjunto de réplicas.

• kind: ReplicaSet → Definimos o tipo como o conjunto de réplicas, o que ajuda o kubectl a entender que o arquivo é usado para criar um conjunto de réplicas.

• tier: Backend → Definimos a camada de rótulo como backend que cria um seletor correspondente.

• {key: tier, operation: In, values: [Backend]} → Isso vai ajudar matchExpression para entender a condição de correspondência que definimos e na operação que é usada por matchlabel para encontrar detalhes.

Execute o arquivo acima usando kubectl e criar o conjunto de réplicas de back-end com a definição fornecida no yaml Arquivo.

As implantações são atualizadas e uma versão superior do controlador de replicação. Eles gerenciam a implantação de conjuntos de réplicas, que também são uma versão atualizada do controlador de replicação. Eles têm a capacidade de atualizar o conjunto de réplicas e também podem reverter para a versão anterior.

Eles fornecem muitos recursos atualizados de matchLabels e selectors. Temos um novo controlador no mestre do Kubernetes chamado controlador de implantação, que faz isso acontecer. Ele tem a capacidade de alterar a implantação no meio do caminho.

Mudando a implantação

Updating- O usuário pode atualizar a implantação em andamento antes de ser concluída. Nesse caso, a implantação existente será resolvida e uma nova implantação será criada.

Deleting- O usuário pode pausar / cancelar a implantação, excluindo-o antes de ser concluído. Recriar a mesma implantação irá retomá-la.

Rollback- Podemos reverter a implantação ou a implantação em andamento. O usuário pode criar ou atualizar a implantação usandoDeploymentSpec.PodTemplateSpec = oldRC.PodTemplateSpec.

Estratégias de implantação

As estratégias de implantação ajudam a definir como o novo RC deve substituir o existente.

Recreate- Este recurso eliminará todos os RC existentes e, em seguida, exibirá os novos. Isso resulta em implantação rápida, mas resultará em tempo de inatividade quando os pods antigos estiverem inativos e os novos não surgirem.

Rolling Update- Este recurso desativa gradualmente o RC antigo e ativa o novo. Isso resulta em uma implantação lenta; no entanto, não há implantação. Em todos os momentos, poucos pods antigos e alguns novos estão disponíveis nesse processo.

O arquivo de configuração do Deployment se parece com isso.

apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   template:
      metadata:
         lables:
            app: Tomcat-ReplicaSet
            tier: Backend
   spec:
      containers:
         - name: Tomcatimage:
            tomcat: 8.0
            ports:
               - containerPort: 7474

No código acima, a única coisa que é diferente do conjunto de réplicas é que definimos o tipo como implantação.

Criar implantação

$ kubectl create –f Deployment.yaml -–record
deployment "Deployment" created Successfully.

Busque a implantação

$ kubectl get deployments
NAME           DESIRED     CURRENT     UP-TO-DATE     AVILABLE    AGE
Deployment        3           3           3              3        20s

Verifique o status de implantação

$ kubectl rollout status deployment/Deployment

Atualizando a implantação

$ kubectl set image deployment/Deployment tomcat=tomcat:6.0

Revertendo para a implantação anterior

$ kubectl rollout undo deployment/Deployment –to-revision=2

No Kubernetes, um volume pode ser considerado um diretório acessível aos contêineres de um pod. Temos diferentes tipos de volumes no Kubernetes e o tipo define como o volume é criado e seu conteúdo.

O conceito de volume estava presente no Docker, no entanto, o único problema era que o volume era muito limitado a um pod específico. Assim que a vida de um pod acabou, o volume também foi perdido.

Por outro lado, os volumes criados por meio do Kubernetes não se limitam a nenhum contêiner. Ele é compatível com qualquer um ou todos os contêineres implantados dentro do pod do Kubernetes. Uma das principais vantagens do volume Kubernetes é que ele oferece suporte a diferentes tipos de armazenamento, em que o pod pode usar vários deles ao mesmo tempo.

Tipos de volume do Kubernetes

Aqui está uma lista de alguns volumes populares do Kubernetes -

• emptyDir- É um tipo de volume criado quando um pod é atribuído pela primeira vez a um nó. Ele permanece ativo enquanto o pod estiver em execução nesse nó. O volume está inicialmente vazio e os contêineres no pod podem ler e gravar os arquivos no volume emptyDir. Depois que o pod é removido do nó, os dados em emptyDir são apagados.

• hostPath - Este tipo de volume monta um arquivo ou diretório do sistema de arquivos do nó host em seu pod.

• gcePersistentDisk- Este tipo de volume monta um disco permanente do Google Compute Engine (GCE) em seu pod. Os dados em umgcePersistentDisk permanece intacto quando o pod é removido do nó.

• awsElasticBlockStore- Este tipo de volume monta um armazenamento Elastic Block da Amazon Web Services (AWS) em seu pod. Assim comogcePersistentDisk, os dados em um awsElasticBlockStore permanece intacto quando o pod é removido do nó.

• nfs - um nfsvolume permite que um NFS (Network File System) existente seja montado em seu pod. Os dados em umnfso volume não é apagado quando o pod é removido do nó. O volume está apenas desmontado.

• iscsi - um iscsi volume permite que um volume iSCSI (SCSI sobre IP) existente seja montado em seu pod.

• flocker- É um gerenciador de volume de dados de contêiner em cluster de código aberto. É usado para gerenciar volumes de dados. UMAflockervolume permite que um conjunto de dados Flocker seja montado em um pod. Se o conjunto de dados não existir no Flocker, você primeiro precisa criá-lo usando a API do Flocker.

• glusterfs- Glusterfs é um sistema de arquivos em rede de código aberto. Um volume glusterfs permite que um volume glusterfs seja montado em seu pod.

• rbd- RBD significa Rados Block Device. Arbdvolume permite que um volume do Rados Block Device seja montado em seu pod. Os dados permanecem preservados depois que o pod é removido do nó.

• cephfs - A cephfsvolume permite que um volume CephFS existente seja montado em seu pod. Os dados permanecem intactos depois que o pod é removido do nó.

• gitRepo - A gitRepo volume monta um diretório vazio e clona um git repositório nele para seu pod usar.

• secret - A secret volume é usado para passar informações confidenciais, como senhas, para pods.

• persistentVolumeClaim - A persistentVolumeClaimvolume é usado para montar um PersistentVolume em um pod. PersistentVolumes são uma forma de os usuários “reivindicarem” armazenamento durável (como um PersistentDisk GCE ou um volume iSCSI) sem saber os detalhes do ambiente de nuvem específico.

• downwardAPI - A downwardAPIo volume é usado para disponibilizar os dados da API descendente para os aplicativos. Ele monta um diretório e grava os dados solicitados em arquivos de texto simples.

• azureDiskVolume - um AzureDiskVolume é usado para montar um disco de dados do Microsoft Azure em um pod.

Volume Persistente e Reivindicação de Volume Persistente

Persistent Volume (PV)- É um pedaço de armazenamento de rede que foi provisionado pelo administrador. É um recurso no cluster independente de qualquer pod individual que usa o PV.

Persistent Volume Claim (PVC)- O armazenamento solicitado pelo Kubernetes para seus pods é conhecido como PVC. O usuário não precisa saber o provisionamento subjacente. As declarações devem ser criadas no mesmo namespace em que o pod foi criado.

Criação de volume persistente

kind: PersistentVolume ---------> 1
apiVersion: v1
metadata:
   name: pv0001 ------------------> 2
   labels:
      type: local
spec:
   capacity: -----------------------> 3
      storage: 10Gi ----------------------> 4
   accessModes:
      - ReadWriteOnce -------------------> 5
      hostPath:
         path: "/tmp/data01" --------------------------> 6

No código acima, definimos -

• kind: PersistentVolume → Definimos o tipo como PersistentVolume, que informa ao kubernetes que o arquivo yaml usado é para criar o volume persistente.

• name: pv0001 → Nome do PersistentVolume que estamos criando.

• capacity: → Esta especificação definirá a capacidade de PV que estamos tentando criar.

• storage: 10Gi → Isso informa à infraestrutura subjacente que estamos tentando reivindicar espaço 10Gi no caminho definido.

• ReadWriteOnce → Isso informa os direitos de acesso do volume que estamos criando.

• path: "/tmp/data01" → Esta definição diz à máquina que estamos tentando criar volume sob este caminho na infraestrutura subjacente.

Criando PV

$ kubectl create –f local-01.yaml
persistentvolume "pv0001" created

Verificando PV

$ kubectl get pv
NAME        CAPACITY      ACCESSMODES       STATUS       CLAIM      REASON     AGE
pv0001        10Gi            RWO         Available                            14s

Descrevendo PV

$ kubectl describe pv pv0001

Criação de reivindicação de volume persistente

kind: PersistentVolumeClaim --------------> 1
apiVersion: v1
metadata:
   name: myclaim-1 --------------------> 2
spec:
   accessModes:
      - ReadWriteOnce ------------------------> 3
   resources:
      requests:
         storage: 3Gi ---------------------> 4

No código acima, definimos -

• kind: PersistentVolumeClaim → Instrui a infraestrutura subjacente que estamos tentando reivindicar uma quantidade especificada de espaço.

• name: myclaim-1 → Nome da reivindicação que estamos tentando criar.

• ReadWriteOnce → Isso especifica o modo da declaração que estamos tentando criar.

• storage: 3Gi → Isso informará ao kubernetes sobre a quantidade de espaço que estamos tentando reivindicar.

Criando PVC

$ kubectl create –f myclaim-1
persistentvolumeclaim "myclaim-1" created

Obtendo detalhes sobre o PVC

$ kubectl get pvc
NAME        STATUS   VOLUME   CAPACITY   ACCESSMODES   AGE
myclaim-1   Bound    pv0001     10Gi         RWO       7s

Descrever PVC

$ kubectl describe pv pv0001

Usando PV e PVC com POD

kind: Pod
apiVersion: v1
metadata:
   name: mypod
   labels:
      name: frontendhttp
spec:
   containers:
   - name: myfrontend
      image: nginx
      ports:
      - containerPort: 80
         name: "http-server"
      volumeMounts: ----------------------------> 1
      - mountPath: "/usr/share/tomcat/html"
         name: mypd
   volumes: -----------------------> 2
      - name: mypd
         persistentVolumeClaim: ------------------------->3
         claimName: myclaim-1

No código acima, definimos -

• volumeMounts: → Este é o caminho do contêiner em que a montagem será realizada.

• Volume: → Esta definição define a definição de volume que vamos reivindicar.

• persistentVolumeClaim: → Abaixo, definimos o nome do volume que vamos usar no pod definido.

Os segredos podem ser definidos como objetos Kubernetes usados ​​para armazenar dados confidenciais, como nome de usuário e senhas com criptografia.

Existem várias maneiras de criar segredos no Kubernetes.

• Criação de arquivos txt.
• Criando a partir do arquivo yaml.

Criação de arquivo de texto

Para criar segredos a partir de um arquivo de texto, como nome de usuário e senha, primeiro precisamos armazená-los em um arquivo txt e usar o seguinte comando.

$ kubectl create secret generic tomcat-passwd –-from-file = ./username.txt –fromfile = ./.
password.txt

Criando a partir do arquivo Yaml

apiVersion: v1
kind: Secret
metadata:
name: tomcat-pass
type: Opaque
data:
   password: <User Password>
   username: <User Name>

Criando o segredo

$ kubectl create –f Secret.yaml
secrets/tomcat-pass

Usando segredos

Depois de criar os segredos, eles podem ser consumidos em um pod ou no controlador de replicação como -

• Variável de ambiente
• Volume

Como Variável de Ambiente

Para usar o segredo como variável de ambiente, vamos usar env na seção de especificações do arquivo yaml do pod.

env:
- name: SECRET_USERNAME
   valueFrom:
      secretKeyRef:
         name: mysecret
         key: tomcat-pass

Como volume

spec:
   volumes:
      - name: "secretstest"
         secret:
            secretName: tomcat-pass
   containers:
      - image: tomcat:7.0
         name: awebserver
         volumeMounts:
            - mountPath: "/tmp/mysec"
            name: "secretstest"

Configuração secreta como variável de ambiente

apiVersion: v1
kind: ReplicationController
metadata:
   name: appname
spec:
replicas: replica_count
template:
   metadata:
      name: appname
   spec:
      nodeSelector:
         resource-group:
      containers:
         - name: appname
            image:
            imagePullPolicy: Always
            ports:
            - containerPort: 3000
            env: -----------------------------> 1
               - name: ENV
                  valueFrom:
                     configMapKeyRef:
                        name: appname
                        key: tomcat-secrets

No código acima, sob o env definição, estamos usando segredos como variável de ambiente no controlador de replicação.

Segredos como montagem de volume

apiVersion: v1
kind: pod
metadata:
   name: appname
spec:
   metadata:
      name: appname
   spec:
   volumes:
      - name: "secretstest"
         secret:
            secretName: tomcat-pass
   containers:
      - image: tomcat: 8.0
         name: awebserver
         volumeMounts:
            - mountPath: "/tmp/mysec"
            name: "secretstest"

A política de rede define como os pods no mesmo namespace se comunicarão entre si e com o endpoint da rede. Isso requerextensions/v1beta1/networkpoliciespara ser ativado na configuração de tempo de execução no servidor API. Seus recursos usam rótulos para selecionar os pods e definir regras para permitir o tráfego para um pod específico, além do que é definido no namespace.

Primeiro, precisamos configurar a Política de Isolamento de Namespace. Basicamente, esse tipo de política de rede é necessária nos balanceadores de carga.

kind: Namespace
apiVersion: v1
metadata:
   annotations:
      net.beta.kubernetes.io/network-policy: |
      {
         "ingress": 
         {
            "isolation": "DefaultDeny"
         }
      }

$ kubectl annotate ns <namespace> "net.beta.kubernetes.io/network-policy = 
{\"ingress\": {\"isolation\": \"DefaultDeny\"}}"

Uma vez que o namespace é criado, precisamos criar a Política de Rede.

Política de rede Yaml

kind: NetworkPolicy
apiVersion: extensions/v1beta1
metadata:
   name: allow-frontend
   namespace: myns
spec:
   podSelector:
      matchLabels:
         role: backend
   ingress:
   - from:
      - podSelector:
         matchLabels:
            role: frontend
   ports:
      - protocol: TCP
         port: 6379

A API Kubernetes serve como base para o esquema de configuração declarativa do sistema. KubectlA ferramenta de linha de comando pode ser usada para criar, atualizar, excluir e obter o objeto API. A API Kubernetes atua como um comunicador entre os diferentes componentes do Kubernetes.

Adicionar API ao Kubernetes

Adicionar uma nova API ao Kubernetes adicionará novos recursos ao Kubernetes, o que aumentará a funcionalidade do Kubernetes. No entanto, ao lado disso, também aumentará o custo e a capacidade de manutenção do sistema. A fim de criar um equilíbrio entre o custo e a complexidade, existem alguns conjuntos definidos para ele.

A API que está sendo adicionada deve ser útil para mais de 50% dos usuários. Não há outra maneira de implementar a funcionalidade no Kubernetes. Circunstâncias excepcionais são discutidas na reunião da comunidade do Kubernetes e, em seguida, a API é adicionada.

Mudanças de API

Para aumentar a capacidade do Kubernetes, mudanças são continuamente introduzidas no sistema. Isso é feito pela equipe do Kubernetes para adicionar a funcionalidade ao Kubernetes sem remover ou impactar a funcionalidade existente do sistema.

Para demonstrar o processo geral, aqui está um exemplo (hipotético) -

• Um usuário faz um POST de um objeto Pod para /api/v7beta1/...

• O JSON é desempacotado em um v7beta1.Pod estrutura

• Os valores padrão são aplicados ao v7beta1.Pod

• o v7beta1.Pod é convertido em um api.Pod estrutura

• o api.Pod é validado e todos os erros são devolvidos ao usuário

• o api.Pod é convertido para um v6.Pod (porque v6 é a versão estável mais recente)

• o v6.Pod é empacotado em JSON e escrito para etcd

Agora que temos o objeto Pod armazenado, um usuário pode OBTER esse objeto em qualquer versão de API compatível. Por exemplo -

• Um usuário obtém o pod de /api/v5/...

• O JSON é lido de etcd e unmarshalled dentro de v6.Pod estrutura

• Os valores padrão são aplicados ao v6.Pod

• o v6.Pod é convertido em uma estrutura api.Pod

• o api.Pod é convertido em um v5.Pod estrutura

• o v5.Pod é empacotado em JSON e enviado ao usuário

A implicação desse processo é que as alterações da API devem ser feitas com cuidado e com compatibilidade retroativa.

Controle de versão de API

Para facilitar o suporte a várias estruturas, o Kubernetes oferece suporte a várias versões de API, cada uma em um caminho de API diferente, como /api/v1 ou /apsi/extensions/v1beta1

Os padrões de controle de versão no Kubernetes são definidos em vários padrões.

Nível Alfa

• Esta versão contém alfa (por exemplo, v1alpha1)

• Esta versão pode apresentar erros; a versão habilitada pode ter bugs

• O suporte para bugs pode ser eliminado a qualquer momento.

• Recomendado para ser usado em testes de curto prazo apenas porque o suporte pode não estar presente o tempo todo.

Nível Beta

• O nome da versão contém beta (por exemplo, v2beta3)

• O código foi totalmente testado e a versão habilitada deve ser estável.

• O suporte do recurso não será descartado; pode haver algumas pequenas mudanças.

• Recomendado apenas para usos não críticos para os negócios devido ao potencial de alterações incompatíveis em releases subsequentes.

Nível Estável

• O nome da versão é vX Onde X é um número inteiro.

• Versões estáveis ​​de recursos aparecerão no software lançado para muitas versões subsequentes.

Kubectl é o utilitário de linha de comando para interagir com a API Kubernetes. É uma interface usada para comunicar e gerenciar pods no cluster Kubernetes.

É necessário configurar o kubectl para local para interagir com o cluster do Kubernetes.

Configurando Kubectl

Baixe o executável para a estação de trabalho local usando o comando curl.

Em Linux

$ curl -O https://storage.googleapis.com/kubernetesrelease/
release/v1.5.2/bin/linux/amd64/kubectl

Na estação de trabalho OS X

$ curl -O https://storage.googleapis.com/kubernetesrelease/
release/v1.5.2/bin/darwin/amd64/kubectl

Após a conclusão do download, mova os binários no caminho do sistema.

$ chmod +x kubectl
$ mv kubectl /usr/local/bin/kubectl

Configurando Kubectl

A seguir estão as etapas para executar a operação de configuração.

$ kubectl config set-cluster default-cluster --server = https://${MASTER_HOST} -- certificate-authority = ${CA_CERT}

$ kubectl config set-credentials default-admin --certificateauthority = ${
CA_CERT} --client-key = ${ADMIN_KEY} --clientcertificate = ${
ADMIN_CERT}

$ kubectl config set-context default-system --cluster = default-cluster -- user = default-admin $ kubectl config use-context default-system

• Substituir ${MASTER_HOST} com o endereço ou nome do nó mestre usado nas etapas anteriores.

• Substituir ${CA_CERT} com o caminho absoluto para o ca.pem criado nas etapas anteriores.

• Substituir ${ADMIN_KEY} com o caminho absoluto para o admin-key.pem criado nas etapas anteriores.

• Substituir ${ADMIN_CERT} com o caminho absoluto para o admin.pem criado nas etapas anteriores.

Verificando a configuração

Para verificar se o kubectl está funcionando bem ou não, verifique se o cliente Kubernetes está configurado corretamente.

$ kubectl get nodes

NAME       LABELS                                     STATUS
Vipin.com  Kubernetes.io/hostname = vipin.mishra.com    Ready

Kubectlcontrola o cluster do Kubernetes. É um dos principais componentes do Kubernetes, que é executado na estação de trabalho de qualquer máquina quando a configuração é concluída. Ele tem a capacidade de gerenciar os nós no cluster.

Kubectlcomandos são usados ​​para interagir e gerenciar objetos Kubernetes e o cluster. Neste capítulo, discutiremos alguns comandos usados ​​no Kubernetes via kubectl.

kubectl annotate - Atualiza a anotação em um recurso.

$kubectl annotate [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ...
KEY_N = VAL_N [--resource-version = version]

Por exemplo,

kubectl annotate pods tomcat description = 'my frontend'

kubectl api-versions - Imprime as versões suportadas da API no cluster.

$ kubectl api-version;

kubectl apply - Tem a capacidade de configurar um recurso por arquivo ou stdin.

$ kubectl apply –f <filename>

kubectl attach - Isso anexa coisas ao contêiner em execução.

$ kubectl attach <pod> –c <container> $ kubectl attach 123456-7890 -c tomcat-conatiner

kubectl autoscale - Isso é usado para escalonar automaticamente os pods que são definidos como implantação, conjunto de réplicas, controlador de replicação.

$ kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min = MINPODS] -- max = MAXPODS [--cpu-percent = CPU] [flags] $ kubectl autoscale deployment foo --min = 2 --max = 10

kubectl cluster-info - Exibe as informações do cluster.

$ kubectl cluster-info

kubectl cluster-info dump - Ele despeja informações relevantes sobre o cluster para depuração e diagnóstico.

$ kubectl cluster-info dump
$ kubectl cluster-info dump --output-directory = /path/to/cluster-state

kubectl config - Modifica o arquivo kubeconfig.

$ kubectl config <SUBCOMMAD>
$ kubectl config –-kubeconfig <String of File name>

kubectl config current-context - Mostra o contexto atual.

$ kubectl config current-context
#deploys the current context

kubectl config delete-cluster - Exclui o cluster especificado de kubeconfig.

$ kubectl config delete-cluster <Cluster Name>

kubectl config delete-context - Exclui um contexto especificado de kubeconfig.

$ kubectl config delete-context <Context Name>

kubectl config get-clusters - Exibe o cluster definido no kubeconfig.

$ kubectl config get-cluster $ kubectl config get-cluster <Cluser Name>

kubectl config get-contexts - Descreve um ou vários contextos.

$ kubectl config get-context <Context Name>

kubectl config set-cluster - Define a entrada do cluster no Kubernetes.

$ kubectl config set-cluster NAME [--server = server] [--certificateauthority =
path/to/certificate/authority] [--insecure-skip-tls-verify = true]

kubectl config set-context - define uma entrada de contexto no ponto de entrada do kubernetes.

$ kubectl config set-context NAME [--cluster = cluster_nickname] [-- user = user_nickname] [--namespace = namespace] $ kubectl config set-context prod –user = vipin-mishra

kubectl config set-credentials - Define uma entrada de usuário em kubeconfig.

$ kubectl config set-credentials cluster-admin --username = vipin --
password = uXFGweU9l35qcif

kubectl config set - Define um valor individual no arquivo kubeconfig.

$ kubectl config set PROPERTY_NAME PROPERTY_VALUE

kubectl config unset - Ele cancela a configuração de um componente específico em kubectl.

$ kubectl config unset PROPERTY_NAME PROPERTY_VALUE

kubectl config use-context - Define o contexto atual no arquivo kubectl.

$ kubectl config use-context <Context Name>

kubectl config view

$ kubectl config view $ kubectl config view –o jsonpath='{.users[?(@.name == "e2e")].user.password}'

kubectl cp - Copie arquivos e diretórios de e para contêineres.

$ kubectl cp <Files from source> <Files to Destinatiion> $ kubectl cp /tmp/foo <some-pod>:/tmp/bar -c <specific-container>

kubectl create- Para criar recursos por nome de arquivo ou stdin. Para fazer isso, os formatos JSON ou YAML são aceitos.

$ kubectl create –f <File Name> $ cat <file name> | kubectl create –f -

Da mesma forma, podemos criar várias coisas conforme listado usando o create comando junto com kubectl.

• deployment
• namespace
• quota
• registro docker secreto
• secret
• segredo genérico
• tls secretos
• serviceaccount
• serviço clusterip
• balanceador de carga de serviço
• nodeport de serviço

kubectl delete - Exclui recursos por nome de arquivo, stdin, recurso e nomes.

$ kubectl delete –f ([-f FILENAME] | TYPE [(NAME | -l label | --all)])

kubectl describe- Descreve qualquer recurso específico em kubernetes. Mostra detalhes do recurso ou um grupo de recursos.

$ kubectl describe <type> <type name>
$ kubectl describe pod tomcat

kubectl drain- Isso é usado para drenar um nó para fins de manutenção. Ele prepara o nó para manutenção. Isso marcará o nó como indisponível para que ele não seja atribuído com um novo contêiner que será criado.

$ kubectl drain tomcat –force

kubectl edit- É usado para encerrar os recursos no servidor. Isso permite editar diretamente um recurso que pode ser recebido por meio da ferramenta de linha de comando.

$ kubectl edit <Resource/Name | File Name) Ex. $ kubectl edit rc/tomcat

kubectl exec - Isso ajuda a executar um comando no contêiner.

$ kubectl exec POD <-c CONTAINER > -- COMMAND < args...> $ kubectl exec tomcat 123-5-456 date

kubectl expose- Isso é usado para expor os objetos Kubernetes, como pod, controlador de replicação e serviço como um novo serviço Kubernetes. Isso tem a capacidade de expô-lo por meio de um contêiner em execução ou de umyaml Arquivo.

$ kubectl expose (-f FILENAME | TYPE NAME) [--port=port] [--protocol = TCP|UDP] [--target-port = number-or-name] [--name = name] [--external-ip = external-ip-ofservice] [--type = type] $ kubectl expose rc tomcat –-port=80 –target-port = 30000
$ kubectl expose –f tomcat.yaml –port = 80 –target-port =

kubectl get - Este comando é capaz de buscar dados no cluster sobre os recursos do Kubernetes.

$ kubectl get [(-o|--output=)json|yaml|wide|custom-columns=...|custom-columnsfile=...|
go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...]
(TYPE [NAME | -l label] | TYPE/NAME ...) [flags]

Por exemplo,

$ kubectl get pod <pod name> $ kubectl get service <Service name>

kubectl logs- Eles são usados ​​para obter os logs do contêiner em um pod. A impressão dos logs pode definir o nome do contêiner no pod. Se o POD possuir apenas um container, não há necessidade de definir seu nome.

$ kubectl logs [-f] [-p] POD [-c CONTAINER] Example $ kubectl logs tomcat.
$ kubectl logs –p –c tomcat.8

kubectl port-forward - Eles são usados ​​para encaminhar uma ou mais portas locais para pods.

$ kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT
[...[LOCAL_PORT_N:]REMOTE_PORT_N]
$ kubectl port-forward tomcat 3000 4000 $ kubectl port-forward tomcat 3000:5000

kubectl replace - Capaz de substituir um recurso por nome de arquivo ou stdin.

$ kubectl replace -f FILENAME $ kubectl replace –f tomcat.yml
$ cat tomcat.yml | kubectl replace –f -

kubectl rolling-update- Executa uma atualização contínua em um controlador de replicação. Substitui o controlador de replicação especificado por um novo controlador de replicação, atualizando um POD por vez.

$ kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --
image = NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC)
$ kubectl rolling-update frontend-v1 –f freontend-v2.yaml

kubectl rollout - É capaz de gerenciar o rollout de implantação.

$ Kubectl rollout <Sub Command>
$ kubectl rollout undo deployment/tomcat

Além do acima, podemos realizar várias tarefas usando o rollout, como -

• histórico de lançamento
• pausa de lançamento
• rollout resume
• status de lançamento
• rollout desfazer

kubectl run - O comando Executar tem a capacidade de executar uma imagem no cluster Kubernetes.

$ kubectl run NAME --image = image [--env = "key = value"] [--port = port] [--
replicas = replicas] [--dry-run = bool] [--overrides = inline-json] [--command] --
[COMMAND] [args...]
$ kubectl run tomcat --image = tomcat:7.0 $ kubectl run tomcat –-image = tomcat:7.0 –port = 5000

kubectl scale - Ele dimensionará o tamanho das implantações do Kubernetes, ReplicaSet, controlador de replicação ou trabalho.

$ kubectl scale [--resource-version = version] [--current-replicas = count] -- replicas = COUNT (-f FILENAME | TYPE NAME ) $ kubectl scale –-replica = 3 rs/tomcat
$ kubectl scale –replica = 3 tomcat.yaml

kubectl set image - Atualiza a imagem de um modelo de pod.

$ kubectl set image (-f FILENAME | TYPE NAME)
CONTAINER_NAME_1 = CONTAINER_IMAGE_1 ... CONTAINER_NAME_N = CONTAINER_IMAGE_N
$ kubectl set image deployment/tomcat busybox = busybox ngnix = ngnix:1.9.1 $ kubectl set image deployments, rc tomcat = tomcat6.0 --all

kubectl set resources- É usado para definir o conteúdo do recurso. Ele atualiza recursos / limites no objeto com o modelo de pod.

$ kubectl set resources (-f FILENAME | TYPE NAME) ([--limits = LIMITS & -- requests = REQUESTS] $ kubectl set resources deployment tomcat -c = tomcat --
limits = cpu = 200m,memory = 512Mi

kubectl top node- Exibe o uso de CPU / memória / armazenamento. O comando top permite que você veja o consumo de recursos para os nós.

$ kubectl top node [node Name]

O mesmo comando também pode ser usado com um pod.

Para criar um aplicativo para implantação do Kubernetes, primeiro precisamos criar o aplicativo no Docker. Isso pode ser feito de duas maneiras -

• Baixando
• Do arquivo Docker

Baixando

A imagem existente pode ser baixada do hub Docker e armazenada no registro Docker local.

Para fazer isso, execute o Docker pull comando.

$ docker pull --help
Usage: docker pull [OPTIONS] NAME[:TAG|@DIGEST]
Pull an image or a repository from the registry
   -a, --all-tags = false     Download all tagged images in the repository
   --help = false             Print usage

A seguir será a saída do código acima.

A captura de tela acima mostra um conjunto de imagens que são armazenadas em nosso registro Docker local.

Se quisermos construir um contêiner a partir da imagem que consiste em um aplicativo para teste, podemos fazer isso usando o comando run do Docker.

$ docker run –i –t unbunt /bin/bash

Do arquivo Docker

Para criar um aplicativo a partir do arquivo Docker, precisamos primeiro criar um arquivo Docker.

A seguir está um exemplo de arquivo Jenkins Docker.

FROM ubuntu:14.04
MAINTAINER [email protected]
ENV REFRESHED_AT 2017-01-15
RUN apt-get update -qq && apt-get install -qqy curl
RUN curl https://get.docker.io/gpg | apt-key add -
RUN echo deb http://get.docker.io/ubuntu docker main > /etc/apt/↩
sources.list.d/docker.list
RUN apt-get update -qq && apt-get install -qqy iptables ca-↩
certificates lxc openjdk-6-jdk git-core lxc-docker
ENV JENKINS_HOME /opt/jenkins/data
ENV JENKINS_MIRROR http://mirrors.jenkins-ci.org
RUN mkdir -p $JENKINS_HOME/plugins
RUN curl -sf -o /opt/jenkins/jenkins.war -L $JENKINS_MIRROR/war-↩ stable/latest/jenkins.war RUN for plugin in chucknorris greenballs scm-api git-client git ↩ ws-cleanup ;\ do curl -sf -o $JENKINS_HOME/plugins/${plugin}.hpi \ -L $JENKINS_MIRROR/plugins/${plugin}/latest/${plugin}.hpi ↩
; done
ADD ./dockerjenkins.sh /usr/local/bin/dockerjenkins.sh
RUN chmod +x /usr/local/bin/dockerjenkins.sh
VOLUME /var/lib/docker
EXPOSE 8080
ENTRYPOINT [ "/usr/local/bin/dockerjenkins.sh" ]

Depois que o arquivo acima for criado, salve-o com o nome de Dockerfile e cd no caminho do arquivo. Em seguida, execute o seguinte comando.

$ sudo docker build -t jamtur01/Jenkins .

Depois que a imagem é construída, podemos testar se a imagem está funcionando bem e pode ser convertida em um contêiner.

$ docker run –i –t jamtur01/Jenkins /bin/bash

A implantação é um método de conversão de imagens em contêineres e, em seguida, alocação dessas imagens em pods no cluster do Kubernetes. Isso também ajuda a configurar o cluster de aplicativo, que inclui implantação de serviço, pod, controlador de replicação e conjunto de réplicas. O cluster pode ser configurado de forma que os aplicativos implantados no pod possam se comunicar uns com os outros.

Nesta configuração, podemos ter uma configuração de balanceador de carga em cima de um aplicativo, desviando o tráfego para um conjunto de pods e, posteriormente, eles se comunicam com os pods de back-end. A comunicação entre os pods acontece por meio do objeto de serviço criado no Kubernetes.

Arquivo Yaml do balanceador de carga Ngnix

apiVersion: v1
kind: Service
metadata:
   name: oppv-dev-nginx
      labels:
         k8s-app: omni-ppv-api
spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: omninginx
   selector:
      k8s-app: appname
      component: nginx
      env: dev

Controlador de replicação Ngnix Yaml

apiVersion: v1
kind: ReplicationController
metadata:
   name: appname
spec:
   replicas: replica_count
   template:
      metadata:
         name: appname
         labels:
            k8s-app: appname
            component: nginx
               env: env_name
spec:
   nodeSelector:
      resource-group: oppv
   containers:
      - name: appname
      image: IMAGE_TEMPLATE
      imagePullPolicy: Always
      ports:
         - containerPort: 8080
         resources:
            requests:
               memory: "request_mem"
               cpu: "request_cpu"
            limits:
               memory: "limit_mem"
               cpu: "limit_cpu"
            env:
            - name: BACKEND_HOST
               value: oppv-env_name-node:3000

Arquivo Yaml de serviço de front-end

apiVersion: v1
kind: Service
metadata:
   name: appname
   labels:
      k8s-app: appname
spec:
   type: NodePort
   ports:
   - name: http
      port: 3000
      protocol: TCP
      targetPort: 3000
   selector:
      k8s-app: appname
      component: nodejs
      env: dev

Arquivo Yaml do controlador de replicação de front-end

apiVersion: v1
kind: ReplicationController
metadata:
   name: Frontend
spec:
   replicas: 3
   template:
      metadata:
         name: frontend
         labels:
            k8s-app: Frontend
            component: nodejs
            env: Dev
spec:
   nodeSelector:
      resource-group: oppv
   containers:
      - name: appname
         image: IMAGE_TEMPLATE
         imagePullPolicy: Always
         ports:
            - containerPort: 3000
            resources:
               requests:
                  memory: "request_mem"
                  cpu: "limit_cpu"
                  limits:
                  memory: "limit_mem"
                  cpu: "limit_cpu"
            env:
               - name: ENV
               valueFrom:
               configMapKeyRef:
               name: appname
               key: config-env

Arquivo Yaml de serviço de back-end

apiVersion: v1
kind: Service
metadata:
   name: backend
   labels:
      k8s-app: backend
spec:
   type: NodePort
   ports:
   - name: http
      port: 9010
      protocol: TCP
      targetPort: 9000
   selector:
      k8s-app: appname
      component: play
      env: dev

Arquivo Yaml do controlador de replicação com suporte

apiVersion: v1
kind: ReplicationController
metadata:
   name: backend
spec:
   replicas: 3
   template:
      metadata:
         name: backend
      labels:
         k8s-app: beckend
         component: play
         env: dev
spec:
   nodeSelector:
      resource-group: oppv
      containers:
         - name: appname
            image: IMAGE_TEMPLATE
            imagePullPolicy: Always
            ports:
            - containerPort: 9000
            command: [ "./docker-entrypoint.sh" ]
            resources:
               requests:
                  memory: "request_mem"
                  cpu: "request_cpu"
               limits:
                  memory: "limit_mem"
                  cpu: "limit_cpu"
            volumeMounts:
               - name: config-volume
               mountPath: /app/vipin/play/conf
         volumes:
            - name: config-volume
            configMap:
            name: appname

Autoscalingé um dos principais recursos do cluster Kubernetes. É um recurso no qual o cluster é capaz de aumentar o número de nós conforme a demanda por resposta de serviço aumenta e diminui o número de nós conforme o requisito diminui. Este recurso de escalonamento automático é atualmente compatível com o Google Cloud Engine (GCE) e o Google Container Engine (GKE) e começará com a AWS em breve.

Para configurar a infraestrutura escalonável no GCE, primeiro precisamos ter um projeto GCE ativo com recursos de monitoramento de nuvem do Google, registro em nuvem do Google e stackdriver habilitado.

Primeiro, vamos configurar o cluster com poucos nós em execução. Uma vez feito isso, precisamos configurar a seguinte variável de ambiente.

Variável de ambiente

export NUM_NODES = 2
export KUBE_AUTOSCALER_MIN_NODES = 2
export KUBE_AUTOSCALER_MAX_NODES = 5
export KUBE_ENABLE_CLUSTER_AUTOSCALER = true

Uma vez feito isso, vamos iniciar o cluster executando kube-up.sh. Isso criará um cluster junto com o complemento auto-escalar do cluster.

./cluster/kube-up.sh

Na criação do cluster, podemos verificar nosso cluster usando o seguinte comando kubectl.

$ kubectl get nodes
NAME                             STATUS                       AGE
kubernetes-master                Ready,SchedulingDisabled     10m
kubernetes-minion-group-de5q     Ready                        10m
kubernetes-minion-group-yhdx     Ready                        8m

Agora, podemos implantar um aplicativo no cluster e, em seguida, ativar o autoescalador de pod horizontal. Isso pode ser feito usando o seguinte comando.

$ kubectl autoscale deployment <Application Name> --cpu-percent = 50 --min = 1 --
max = 10

O comando acima mostra que manteremos pelo menos uma e no máximo 10 réplicas do POD conforme a carga no aplicativo aumenta.

Podemos verificar o status do autoescalador executando o $kubclt get hpacomando. Vamos aumentar a carga nos pods usando o seguinte comando.

$ kubectl run -i --tty load-generator --image = busybox /bin/sh
$ while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done

Podemos verificar o hpa Correndo $ kubectl get hpa comando.

$ kubectl get hpa NAME REFERENCE TARGET CURRENT php-apache Deployment/php-apache/scale 50% 310% MINPODS MAXPODS AGE 1 20 2m $ kubectl get deployment php-apache
NAME         DESIRED    CURRENT    UP-TO-DATE    AVAILABLE   AGE
php-apache      7          7           7            3        4m

Podemos verificar o número de pods em execução usando o seguinte comando.

jsz@jsz-desk2:~/k8s-src$ kubectl get pods
php-apache-2046965998-3ewo6 0/1        Pending 0         1m
php-apache-2046965998-8m03k 1/1        Running 0         1m
php-apache-2046965998-ddpgp 1/1        Running 0         5m
php-apache-2046965998-lrik6 1/1        Running 0         1m
php-apache-2046965998-nj465 0/1        Pending 0         1m
php-apache-2046965998-tmwg1 1/1        Running 0         1m
php-apache-2046965998-xkbw1 0/1        Pending 0         1m

E, finalmente, podemos obter o status do nó.

$ kubectl get nodes
NAME                             STATUS                        AGE
kubernetes-master                Ready,SchedulingDisabled      9m
kubernetes-minion-group-6z5i     Ready                         43s
kubernetes-minion-group-de5q     Ready                         9m
kubernetes-minion-group-yhdx     Ready                         9m

Configurar o painel do Kubernetes envolve várias etapas com um conjunto de ferramentas necessárias como pré-requisitos para configurá-lo.

• Docker (1.3+)
• go (1.5+)
• nodejs (4.2.2+)
• npm (1,3+)
• java (7 +)
• gole (3,9+)
• Kubernetes (1.1.2+)

Configurando o painel

$ sudo apt-get update && sudo apt-get upgrade Installing Python $ sudo apt-get install python
$ sudo apt-get install python3 Installing GCC $ sudo apt-get install gcc-4.8 g++-4.8

Installing make
$ sudo apt-get install make Installing Java $ sudo apt-get install openjdk-7-jdk

Installing Node.js
$ wget https://nodejs.org/dist/v4.2.2/node-v4.2.2.tar.gz $ tar -xzf node-v4.2.2.tar.gz
$ cd node-v4.2.2 $ ./configure
$ make $ sudo make install

Installing gulp
$ npm install -g gulp $ npm install gulp

Verificando versões

Java Version
$ java –version java version "1.7.0_91" OpenJDK Runtime Environment (IcedTea 2.6.3) (7u91-2.6.3-1~deb8u1+rpi1) OpenJDK Zero VM (build 24.91-b01, mixed mode) $ node –v
V4.2.2

$ npn -v 2.14.7 $ gulp -v
[09:51:28] CLI version 3.9.0

$ sudo gcc --version
gcc (Raspbian 4.8.4-1) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc. This is free software; 
see the source for copying conditions. There is NO warranty; not even for 
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Instalando GO

$ git clone https://go.googlesource.com/go
$ cd go $ git checkout go1.4.3
$ cd src Building GO $ ./all.bash
$ vi /root/.bashrc In the .bashrc export GOROOT = $HOME/go
   export PATH = $PATH:$GOROOT/bin
   
$ go version
go version go1.4.3 linux/arm

Instalação do painel Kubernetes

$ git clone https://github.com/kubernetes/dashboard.git
$ cd dashboard $ npm install -g bower

Executando o painel

$ git clone https://github.com/kubernetes/dashboard.git $ cd dashboard
$ npm install -g bower $ gulp serve
[11:19:12] Requiring external module babel-core/register
[11:20:50] Using gulpfile ~/dashboard/gulpfile.babel.js
[11:20:50] Starting 'package-backend-source'...
[11:20:50] Starting 'kill-backend'...
[11:20:50] Finished 'kill-backend' after 1.39 ms
[11:20:50] Starting 'scripts'...
[11:20:53] Starting 'styles'...
[11:21:41] Finished 'scripts' after 50 s
[11:21:42] Finished 'package-backend-source' after 52 s
[11:21:42] Starting 'backend'...
[11:21:43] Finished 'styles' after 49 s
[11:21:43] Starting 'index'...
[11:21:44] Finished 'index' after 1.43 s
[11:21:44] Starting 'watch'...
[11:21:45] Finished 'watch' after 1.41 s
[11:23:27] Finished 'backend' after 1.73 min
[11:23:27] Starting 'spawn-backend'...
[11:23:27] Finished 'spawn-backend' after 88 ms
[11:23:27] Starting 'serve'...
2016/02/01 11:23:27 Starting HTTP server on port 9091
2016/02/01 11:23:27 Creating API client for
2016/02/01 11:23:27 Creating Heapster REST client for http://localhost:8082
[11:23:27] Finished 'serve' after 312 ms
[BS] [BrowserSync SPA] Running...
[BS] Access URLs:
--------------------------------------
Local: http://localhost:9090/
External: http://192.168.1.21:9090/
--------------------------------------
UI: http://localhost:3001
UI External: http://192.168.1.21:3001
--------------------------------------
[BS] Serving files from: /root/dashboard/.tmp/serve
[BS] Serving files from: /root/dashboard/src/app/frontend
[BS] Serving files from: /root/dashboard/src/app

O painel do Kubernetes

O monitoramento é um dos principais componentes para o gerenciamento de grandes clusters. Para isso, dispomos de uma série de ferramentas.

Monitorando com Prometheus

É um sistema de monitoramento e alerta. Ele foi construído no SoundCloud e teve o código aberto em 2012. Ele lida muito bem com os dados multidimensionais.

O Prometheus tem vários componentes para participar do monitoramento -

• Prometheus - É o componente principal que retira e armazena dados.

• Prometheus node explore - Obtém as matrizes de nível de host e as expõe ao Prometheus.

• Ranch-eye - é um haproxy e expõe cAdvisor estatísticas para Prometheus.

• Grafana - Visualização de dados.

• InfuxDB - Banco de dados de série temporal usado especificamente para armazenar dados do fazendeiro.

• Prom-ranch-exporter - É um aplicativo node.js simples, que ajuda a consultar o servidor Rancher sobre o status da pilha de serviço.

Agente Docker Sematext

É um agente moderno de métricas, eventos e coleta de logs que reconhece o Docker. Ele é executado como um pequeno contêiner em cada host Docker e coleta logs, métricas e eventos para todos os nós e contêineres do cluster. Ele descobre todos os contêineres (um pod pode conter vários contêineres), incluindo contêineres para serviços principais do Kubernetes, se os serviços principais forem implantados em contêineres Docker. Após sua implantação, todos os logs e métricas estão imediatamente disponíveis fora da caixa.

Implantando agentes para nós

O Kubernetes fornece DeamonSets, que garante que os pods sejam adicionados ao cluster.

Configurando o SemaText Docker Agent

Ele é configurado por meio de variáveis ​​de ambiente.

• Obtenha uma conta gratuita em apps.sematext.com , se ainda não tiver uma.

• Crie um aplicativo SPM do tipo “Docker” para obter o token de aplicativo SPM. O aplicativo SPM manterá suas métricas e eventos de desempenho do Kubernetes.

• Crie um aplicativo Logsene para obter o token de aplicativo Logsene. O aplicativo Logsene manterá seus registros do Kubernetes.

• Edite os valores de LOGSENE_TOKEN e SPM_TOKEN na definição do DaemonSet conforme mostrado abaixo.

• Pegue o último template sematext-agent-daemonset.yml (texto puro bruto) (também mostrado abaixo).

• Guarde-o em algum lugar do disco.

• Substitua os espaços reservados SPM_TOKEN e LOGSENE_TOKEN por seus tokens de aplicativo SPM e Logsene.

Criar objeto DaemonSet

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
   name: sematext-agent
spec:
   template:
      metadata:
         labels:
            app: sematext-agent
      spec:
         selector: {}
         dnsPolicy: "ClusterFirst"
         restartPolicy: "Always"
         containers:
         - name: sematext-agent
            image: sematext/sematext-agent-docker:latest
            imagePullPolicy: "Always"
            env:
            - name: SPM_TOKEN
               value: "REPLACE THIS WITH YOUR SPM TOKEN"
            - name: LOGSENE_TOKEN
               value: "REPLACE THIS WITH YOUR LOGSENE TOKEN"
            - name: KUBERNETES
               value: "1"
            volumeMounts:
               - mountPath: /var/run/docker.sock
                  name: docker-sock
               - mountPath: /etc/localtime
                  name: localtime
            volumes:
               - name: docker-sock
                  hostPath:
                     path: /var/run/docker.sock
               - name: localtime
                  hostPath:
                     path: /etc/localtime

Executando o Sematext Agent Docker com kubectl

$ kubectl create -f sematext-agent-daemonset.yml
daemonset "sematext-agent-daemonset" created

Registro do Kubernetes

Os registros de contêineres do Kubernetes não são muito diferentes dos registros de contêineres do Docker. No entanto, os usuários do Kubernetes precisam visualizar os registros dos pods implantados. Portanto, é muito útil ter informações específicas do Kubernetes disponíveis para pesquisa de registro, como -

• Namespace Kubernetes
• Nome do pod Kubernetes
• Nome do contêiner Kubernetes
• Nome da imagem do Docker
• UID do Kubernetes

Usando ELK Stack e LogSpout

A pilha ELK inclui Elasticsearch, Logstash e Kibana. Para coletar e encaminhar os logs para a plataforma de registro, usaremos LogSpout (embora existam outras opções, como FluentD).

O código a seguir mostra como configurar o cluster ELK no Kubernetes e criar serviço para ElasticSearch -

apiVersion: v1
kind: Service
metadata:
   name: elasticsearch
   namespace: elk
   labels:
      component: elasticsearch
spec:
   type: LoadBalancer
   selector:
      component: elasticsearch
   ports:
   - name: http
      port: 9200
      protocol: TCP
   - name: transport
      port: 9300
      protocol: TCP

Criando Controlador de Replicação

apiVersion: v1
kind: ReplicationController
metadata:
   name: es
   namespace: elk
   labels:
      component: elasticsearch
spec:
   replicas: 1
   template:
      metadata:
         labels:
            component: elasticsearch
spec:
serviceAccount: elasticsearch
containers:
   - name: es
      securityContext:
      capabilities:
      add:
      - IPC_LOCK
   image: quay.io/pires/docker-elasticsearch-kubernetes:1.7.1-4
   env:
   - name: KUBERNETES_CA_CERTIFICATE_FILE
   value: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
   - name: NAMESPACE
   valueFrom:
      fieldRef:
         fieldPath: metadata.namespace
   - name: "CLUSTER_NAME"
      value: "myesdb"
   - name: "DISCOVERY_SERVICE"
      value: "elasticsearch"
   - name: NODE_MASTER
      value: "true"
   - name: NODE_DATA
      value: "true"
   - name: HTTP_ENABLE
      value: "true"
ports:
- containerPort: 9200
   name: http
   protocol: TCP
- containerPort: 9300
volumeMounts:
- mountPath: /data
   name: storage
volumes:
   - name: storage
      emptyDir: {}

URL Kibana

Para Kibana, fornecemos a URL Elasticsearch como uma variável de ambiente.

- name: KIBANA_ES_URL
value: "http://elasticsearch.elk.svc.cluster.local:9200"
- name: KUBERNETES_TRUST_CERT
value: "true"

A IU Kibana estará acessível na porta do contêiner 5601 e a combinação de host / Node Port correspondente. Quando você começar, não haverá nenhum dado no Kibana (o que é esperado, pois você não enviou nenhum dado).