Implementando Kubernetes com Rancher

Implementando e
Escalando Kubernetes
com Rancher
Agosto de 2016
Vishal Biyani e Girish Shilamkar
©Rancher Labs 2016. All rights reserved. 1

DEPLOYING AND SCALING KUBERNETES WITH RANCHER
©Rancher Labs2016.AllrightsReserved. 2
Contents
Introduction....................................................................................................................................4
1.1 Introduction........................................................................................................................4
1.2 Kubernetes Concepts and Terminology............................................................................4
1.3 Kubernetes Functionalities................................................................................................5
1.3.1 Co-Locating Related Processes ...................................................................................6
1.3.2 Data and Storage...........................................................................................................6
1.3.3 Secret Management.......................................................................................................6
1.3.4 Application Health..........................................................................................................6
1.3.5 Container Management and Scaling.............................................................................6
1.3.6 Service Registry and Discovery ....................................................................................6
1.3.7 Load Balancing..............................................................................................................7
1.3.8 Rolling Updates..............................................................................................................7
1.3.9 Resource Monitoring......................................................................................................7
1.3.10 Log Management ...........................................................................................................7
1.4 Kubernetes Components ..................................................................................................7
1.5 Summary...........................................................................................................................8
2. Deploying Kubernetes with Rancher......................................................................................9
2.1 Rancher Overview.............................................................................................................9
2.2 Native Kubernetes Support in Rancher............................................................................9
2.3 Setting Up a Rancher Kubernetes Environment...............................................................9
2.4 How Rancher Extends Kubernetes for User-Friendly Container Management............. 13
2.4.1 Infrastructure Visibility................................................................................................. 14
2.4.2 GUI-Based CRUD Operations for Kubernetes........................................................... 17
2.4.3 Using kubectl - Credential Management and Web Access ....................................... 20
2.4.4 Simplifying DNS Configuration with Rancher DNS.................................................... 21
2.4.5 Manage Kubernetes Namespaces............................................................................. 22
3 Deploying a Multi-Service Application.......................................................................... 24
3.1 Defining Multi-Service Application.................................................................................. 24
3.2 Designing a Kubernetes service for an Application........................................................ 24
3.3 Load Balancing using Rancher Load Balancing services ............................................. 25
3.4 Service Discovery .......................................................................................................... 30

3.5 Storage............................................................................................................................31
3.6 Secrets ............................................................................................................................32
4 Container Operations.......................................................................................................34
4.1 Continuous Deployment – Service Upgrades and Rollbacks ........................................34
4.1.1 A closer look at deployments ......................................................................................38
4.2 Rancher Private Registry Support for Kubernetes .........................................................39
4.3 Container Monitoring.......................................................................................................40
4.3.1 Monitoring with Prometheus........................................................................................40
4.4 Monitoring with Heapster ................................................................................................44
4.5 Ingress Support...............................................................................................................45
4.5.1 Ingress Use cases.......................................................................................................48
4.6 Container Logging...........................................................................................................49
4.6.1 Using ELK Stack and logspout....................................................................................49
4.7 Auto Scaling ....................................................................................................................54
4.8 Kubernetes System Stack Upgrades in Rancher...........................................................55
5 Building an Application Catalog .....................................................................................59
5.1 Rancher and Community Catalogs.................................................................................59
5.2 One-Click Deployments for Kubernetes Applications.....................................................60
5.3 Creating New Kubernetes Catalog Templates ...............................................................63
6 Additional Resources.......................................................................................................64
7 About the Authors ............................................................................................................65

Introdução
1. Visão geral das capacidades do Kubernetes
1.1 Introdução
Aconteceu Muitas coisas no ecossistema de contêineres nos últimos anos para moldar como o
software é construído e implantado. Para gerenciar uma frota de contêineres executando
microservices, é preciso ter recursos robustos de gerenciamento de clusters que possam lidar
com agendamento, descoberta de serviços, balanceamento de carga, monitoramento e
isolamento de recursos e muito mais. Durante anos, o Google usou um gerente de cluster
chamado Borg para executar milhares de trabalhos, suportando milhares de aplicativos,
rodando em vários clusters. O Google pegou os melhores aspectos do Borg e os forneceu de
forma aberta no projeto Kubernetes, abrindo uma poderosa ferramenta para executar e
gerenciar contêineres em escala.
Neste eBook, iremos analisar as capacidades do Kubernetes, implementar Kubernetes com o
Rancher, implementar e dimensionar alguns exemplos de aplicações de vários níveis. Mas
antes de mergulhar em detalhes, vamos primeiro abordar as capacidades gerais e conceitos de
Kubernetes. Se você tem alguma familiaridade básica com Kubernetes, então você pode
ignorar o restante deste capítulo e ir para Capítulo 2. O Passo a passo Kubernetes 101
(Kubernetes 101 walkthrough) Fornecido pelo próprio projeto Kubernetes fornece um ponto de
partida forte para rever estes conceitos também.
1.2 Kubernetes Conceitos e Terminologia
Vamos levar algum tempo para entender alguns conceitos básicos e terminologia Kubernetes:
Cluster
Um cluster é um conjunto de máquinas (físicas ou virtuais) nas quais seus aplicativos são
gerenciados e executados. Para Kubernetes, todas as máquinas são gerenciadas como um
cluster (ou conjunto de clusters, dependendo da topologia usada).
Node
Uma unidade de máquina lógica (física ou virtual), que faz parte de um cluster maior no qual
você pode executar seus aplicativos.
Pod
Um grupo co-localizado de conteiners e seu armazenamento é chamado de pod. Por exemplo,
faz sentido ter os processos de banco de dados e os contêineres de dados o mais próximo
possível - idealmente eles devem estar no mesmo pod.
Label
Rótulos (Labels) são nomes dados aos recursos para classificá-los, e são sempre um par de
chaves de nome e valor.Os pares chave-valor podem ser usados para filtrar, organizar e
executar operações em massa em um conjunto de recursos. Pense em rótulos como um
papel(role), grupo ou qualquer mecanismo semelhante dado a um contêiner ou recurso. Um
contêiner pode ter uma função de banco de dados, enquanto o outro pode ser um balanceador

de carga. Similarly, all pods could be labeled by geography, with applied values like US, EU,
APAC, etc. If done in the right manner, labels can act as a powerful way to classify resources of
various types.

Selector
Uma expressão de selector(selector) coincide com os rótulos(labels) para filtrar certos recursos. Por
exemplo, você pode querer pesquisar todos os pods que pertencem a um determinado serviço ou
encontrar todos os contêineres que tenham um valor de rótulo(label) de camada específica como
banco de dados. Rótulos(labels) e seletores(selectors) são inerentemente dois lados da mesma
moeda. Você pode usar rótulos(labels) para classificar recursos e usar seletores(selectors) para
encontrá-los e usá-los para determinadas ações.
Replication Controller
Os controladores de replicação (RC) são uma abstração usada para gerenciar ciclos de vida de pod.
Um dos principais usos dos controladores de replicação é manter um certo número de pods. Isso
também é útil quando você deseja ativar certo número de pods para dimensionamento ou garantir que
pelo menos um pod. É uma prática recomendada usar controladores de replicação para definir ciclos
de vida de pod, ao invés de criar pods diretamente.
Replica Sets
Conjuntos de replicas(Replica Sets) definem quantas réplicas de cada pod serão executadas. Eles
também monitoram e asseguram que o número necessário de pods está sendo executado,
substituindo pods que morrem. Conjuntos de réplicas podem atuar como substituições para
controladores de replicação.
Service
Um serviço(Service) é uma abstração em cima de pods que fornece um único endereço IP e nome
DNS pelo qual os pods podem ser acessados. Essa configuração de balanceamento de carga é muito
mais fácil de gerenciar e ajuda a dimensionar os pods sem problemas.
Volume
Um volume é um diretório com dados acessíveis a um contêiner. O volume co-termina com os pods
que o encerram.
Name
Um nome(Name) pelo qual um recurso é identificado.
Namespace
Namespace fornece qualificação adicional para um nome de recurso. Isso é especialmente útil quando
várias equipes/projetos estão usando o mesmo cluster e há um potencial de colisão de nomes. Você
pode pensar no namespace como um muro virtual entre vários clusters.
Annotation
Uma anotação(Annotation) é um rótulo(Label) mas com uma capacidade de dados muito maior.
Normalmente, esses dados não são legíveis por seres humanos e não são fáceis de filtrar. A
anotação é útil somente para armazenar dados que não podem ser pesquisados, mas são
necessários pelo recurso (por exemplo, armazenando chaves fortes, etc.).
1.3 Funcionalidades Kubernetes
No mínimo, qualquer plataforma de orquestração de contêiner precisa ter a capacidade de executar e
programar contêineres. Mas para gerenciar contêineres efetivamente, recursos adicionais são
necessários. Aqui, vamos olhar para as funcionalidades que o Kubernetes tem para gerenciar
contêineres, e ao longo do caminho introduzir alguns conceitos adicionais que Kubernetes usa.

1.3.1 Co-Localizando Processos Relacionados
A maioria das aplicações hoje são construídas a partir de múltiplos componentes ou camadas,
e às vezes estes componentes devem ser fortemente acoplados uns aos outros. Logicamente,
faz sentido co-localizar componentes fortemente acoplados tão perto de permitir uma
comunicação de rede mais fácil e uso de armazenamento compartilhado. Kubernetes permite
co-localizar contêineres relacionados através de pods.
1.3.2 Dados e armazenamento
Pela sua própria natureza, os conteiners são de curta duração. Se um contêiner reinicializar, os
dados dentro dele serão perdidos; Portanto, a introdução de volumes Docker. Os volumes do
Docker carecem de um ciclo de vida definido, como os contêineres(A partir desta data de
publicação). Em contraste, os volumes de Kubernetes estão ligados ao ciclo de vida do
contêiner com o qual os volumes estão associados. Kubernetes também tem vários tipos de
volume para atender a vários casos de uso.
1.3.3 Gerenciamento de Senhas
Aplicações usam segredos como senhas, chaves SSH e tokens API o tempo todo. Para evitar a
divulgação das senhas nos arquivos de configuração que definem contêineres/clusters, o
Kubernetes codifica-os em objetos Secret para posterior referência nos arquivos de
configuração.
1.3.4 Saúde da aplicação
Aplicativos de longa duração podem eventualmente quebrar ou degradar. Kubernetes fornece
uma maneira de verificar a saúde da aplicação como HTTP pontos de extremidade usando
Sondas de vivacidade. Algumas aplicações começam mas não estão prontas para servir
pedidos: por exemplo, ao criar um cache no início do aplicativo. Nestas situações, Kubernetes
fornece uma sonda de prontidão. Por fim, para aplicações que devem terminar deliberadamente
mas graciosamente, Kubernetes fornece ganchos(hooks) de terminação para executar certas
atividades antes que o contêiner seja encerrado.
1.3.5 Gerenciamento e dimensionamento de contêineres
Se um conteiner inesperadamente finaliza sua execução, é importante que ele seja substituído
por um novo. Para conseguir isso, Kubernetes usa um controlador de replicação, o que garante
que um certo número de réplicas de um pod estão sempre em execução. Nos casos em que
apenas uma réplica de um pod precisa estar em execução, seu fator de replicação pode ser
definido como 1. Neste caso, o Kubernetes irá trazê-lo de volta se ele cair. A escala automática
de réplicas de pods pode ser configurada com base em outras condições, como a utilização da
CPU.
1.3.6 Serviço Registro e Descoberta
Considere um vasto cluster executando um grande número de nós. Quando um contêiner falha
em um determinado nó, ele pode ser iniciado em um nó diferente. Como você se assegura de
que todos os outros conteiners que conectam a esse conteiner que falhou receba o endereço
IP do conteiner da recolocação? Esta é uma consideração importante em uma arquitetura de
microservices onde você deve gerenciar dinamicamente os pontos de extremidade do serviço.

Enquanto o Docker permite a rede somente no nível do host (e o Docker Swarm funciona em
hosts), o Kubernetes torna o gerenciamento de rede muito mais fácil, permitindo que qualquer
pod converse com outros pods dentro do mesmo namespace, independentemente do host. Isso
torna muito mais fácil expor as portas e gerenciar links entre diferentes serviços.
1.3.7 Balanceamento de carga
Cada aplicativo que é dimensionado precisa de balanceamento de carga. Em Kubernetes, o
balanceamento de carga pode ser implementado usando uma abstração chamada de "service",
ou com um recurso de tipo de ingresso. Um serviço mascara os conteinrer/conteiners
subjacentes e os representa como uma única entidade. O recurso de entrada funciona expondo
os conteiners subjacentes por meio de um balanceador de carga criado dinamicamente.
Examinaremos ambos os conceitos em detalhes em seções posteriores do livro.
1.3.8 Atualizações contínuas(rolling update)
Muitas aplicações não podem ser retiradas para atualizações por um longo período de tempo e,
em alguns casos, Não pode ser retirada. As atualizações contínuas garantem que um número
mínimo de instâncias esteja sempre disponível, enquanto as instâncias são retiradas do pool
para atualizações. Normalmente, a estratégia é tirar alguma porcentagem de instâncias fora do
serviço, atualizá-las e, em seguida, colocá-las novamente em serviço antes de repetir o
processo com outro conjunto de instâncias.
O Kubernetes suporta atualizações contínuas com o uso de abstrações de "implantação" e
"rolling-update". As implantações são uma adição bastante recente ao projeto, mas fornecem
uma maneira poderosa e declarativa de controlar como as atualizações de serviço são
executadas e recomendadas em relação às atualizações contínuas.
1.3.9 Monitoramento de recursos
Conhecer a saúde dos seus sistemas é fundamental para a execução de um grande cluster.
Kubernetes monitora os clusters em vários níveis. Heapster é usado para agregar métricas
vitais, enquanto o agente do nó kubelet consulta o cAdvisor para buscar dados de contêineres
e fornecer para Heapster. Os dados de desempenho podem ser armazenados no InfluxDB e
visualizados pelo Grafana, ou podem ser alimentados ao monitoramento do Google Cloud para
armazenamento e visualização.
1.3.10 Gerenciamento de Log
A obtenção e análise de dados de log são essenciais para entender o que está acontecendo
com um determinado cluster. Os componentes internos do Kubernetes usam a biblioteca de
registros para registrar dados; Kubectl (a interface de linha de comando) pode ser usado para
buscar dados de log de contêineres. Esses dados podem ser enviados para uma pilha ELK
(Elasticsearch, Logstash e Kibana) ou o registro do Google Cloud para análise e visualização
adicionais.
1.4 Componentes Kubernetes
Kubernetes funciona em um modo de nó mestre, onde um mestre pode gerenciar um grande
número de nós. Alguns componentes são executados somente em mestres, alguns
componentes são executados somente sobre o nó e fornecem todo o suporte de
gerenciamento necessário no nó.

O master pode ser executado no modo HA com uma configuração multi-master. Além dos
componentes listados para o mestre como mostrado no diagrama acima, há componentes
opcionais, tais como: interface do usuário, monitoramento de recursos do contêiner e
componentes relacionados ao log.
1.5 Resumo
A Kubernetes fornece gerenciamento de cluster para cargas de trabalho em contêineres e
simplifica a orquestração de contêineres em escala. Neste capítulo, analisamos as
terminologias de Kubernetes e como a Kubernetes pode ajudar as empresas a adotar
contêineres. Nos capítulos a seguir, veremos como Kubernetes e Rancher podem ser usados
para implantar aplicativos e executar várias operações de contêineres.

0
2. Implantando Kubernetes com Rancher
2.1 Rancher visão Geral
Rancher é uma plataforma de software de código aberto para implementar e gerenciar
contêineres em produção. Inclui distribuições comercialmente suportadas de Kubernetes,
Mesos e Docker Swarm para orquestração de contêineres, e permite que equipes vejam e
gerenciem de forma transparente a infra-estrutura e os contêineres que suportam suas
aplicações. O Rancher oferece recursos internos de autenticação, rede, armazenamento e
balanceamento de carga.
2.2 Rancher tem suporte nativo ao Kubernetes
Rancher suporta nativamente Kubernetes e permite aos usuários controlar suas características
através de uma interface de usuário simples e intuitiva. Kubernetes pode ser executado em
questão de minutos com um único clique através de Rancher. Múltiplas equipes e políticas de
acesso para seus clusters podem ser gerenciadas por meio do Rancher, já que a plataforma se
integra com LDAP, AD e GitHub para autenticação. Uma vez que o cluster está pronto,
qualquer número de hosts pode ser adicionado ao Rancher, em seguida, fornece visibilidade
completa para o desenvolvedor e as equipes de operações em infra-estrutura e aplicações.
Além disso, o Rancher fornece um catálogo de aplicativos com modelos para implantar
aplicativos complexos em um único clique. Os modelos que acompanham o catálogo de
aplicativos podem ser armazenados em um repositório do Git e podem ser compartilhados
entre equipes. Rancher DNS é uma substituição nativa para o Sky DNS, proporcionando assim
gerenciamento de rede transparente, escalável e simplificado em todo o cluster.
2.3 Criação de um ambiente de kubernetes rancher.
Configurar um servidor Rancher é fácil. Você pode configurar um seguindo as instruções Aqui,
Ou se você deseja usar Vagrant, você pode clonar o repo here e executar vagrant up. Quando
você implantar o servidor rancher , você deve ver uma tela que se parece com isto:
Vamos primeiro adicionar um ambiente para o Kubernetes. Um ambiente no Rancher é uma
entidade lógica para o compartilhamento de implantações e recursos com diferentes
conjuntos de usuários e a plataforma permite que você

Escolher entre várias estruturas de orquestração diferentes (Kubernetes, Mesos, Docker
Swarm, e Cattle). Tudo é feito no contexto de um ambiente. Ambientes em Rancher podem
servir como separações lógicas para diferentes equipes dentro de uma empresa, como
desenvolvimento ou controle de qualidade.
Uma vez que o ambiente Kubernetes for criado, podemos adicionar hosts para ele. Escolha
"Adicionar Hosts" no ambiente Kubernetes recém-criado a partir do menu drop-down na parte
superior da tela, onde podemos adicionar uma máquina host de algumas nuvens públicas ou de
uma pilha personalizada. Neste exemplo, escolheremos o método personalizado. Se você
ainda estiver usando o Vagrantfile do repositório Git, configure três nós como descrito abaixo.
Você pode naturalmente mudar isto conforme seu caso de uso.
Hostname Details Docker Version
ranch-svr Rancher Master Latest
Ranch-def Default environment Latest
Ranch-Kubernetes Kubernetes environment 1.10.3 (Kubernetes
compatible)

À medida que adicionamos os detalhes para os hosts, o comando para registrar o host com o
Rancher for modificado. Copie este comando e efetue login em um host que não seja o
Rancher mestre no qual você deseja configurar o seu cluster Kubernetes:
Depois de executar o comando acima em uma nova máquina, o host (s) tenta contatar o
servidor Rancher com a chave. O servidor então verifica a chave e registra o agente. Com base
no ambiente ao qual o agente pertence, outras instruções são enviadas ao agente para trazê-lo
ao seu estado desejado. No nosso caso, uma vez que este é o primeiro e único nó no ambiente
Kubernetes, uma pilha completa de Kubernetes já está configurada no nó (anotação:
começando com Rancher 1.1, é sugerido ter pelo menos três hosts para sua implantação
Kubernetes; Esses hosts para etcd garante uma configuração altamente disponível).

Você verá o cluster Kubernetes sendo configurado (isso pode demorar alguns minutos):
Uma vez que o cluster foi configurado, o menu Kubernetes é preenchido. Se você escolher a
opção Sistema no menu suspenso Kubernetes, você notará que ele mostra os contêineres
relacionados ao mestre Kubernetes:
Você notará neste momento que já existem alguns contêineres em execução no host recém-
adicionado; Vamos examinar a finalidade de cada um desses conteiners:

 Controller-manager é um núcleo de controle loop 1ue observa continuamente o
estado de clusters e toma ações se necessário para trazê-lo para o estado
desejado.
 etcd é um serviço de Alta disponíbilidade (HA) Armazenando pares de chave-valor
para todos os dados persistentes n o cluster. O servidor etcd só deve ser acessível
pelo servidor da API Kubernetes, pois ele pode conter informações confidenciais.
 kubectld é o daemon que executa kubectl.
 kubelet é um nó do agente que é executado em cada nó do cluster para gerenciar
os contêineres executados nesse host.
 kubernetes é o servidor de API que fornece todas as operações CRUD no cluster
através de uma API.
 proxy é outro componente que está sendo executado em cada nó no cluster
Kubernetes e fornece uma rede simples e um balanceador de carga entre hosts.
 scheduler gerencia os pods que ainda não foram atribuídos aos nós e os agende.
 Rancher-kubernetes-agent gerencia a comunicação entre Rancher e o grupo de
Kubernetes
 Rancher-ingress-controller Irá alavancar a funcionalidade de balanceamento de
carga Kubernetes existente no Rancher e converter o que está na entrada do
Kubernetes para um balanceador de carga no Rancher.
2.4 Como o Rancher estende a Kubernetes para uma
gerenciamento de contêiner fácil de usar
Como você deve ter notado na seção anterior, executar Kubernetes é uma brisa no
Rancher. Mas o Rancher tem vários recursos que facilitam o gerenciamento do cluster:
 Rancher simplifica a rede de Kubernetes fornecendo o DNS do Rancher como
uma substituição nativa para o SkyDNS. O cluster Kubernetes pode então se
estender por vários pools de recursos ou nuvens.

 O Rancher permite que as equipes criem e gerenciem vários ambientes do
Kubernetes e disponibilizem o gerenciamento de acesso baseado em funções
(RBAC) para equipes e indivíduos para cada ambiente.
 A interface de usuário intuitiva do Rancher permite executar operações CRUD em
todos os objetos Kubernetes, como pods, controladores de replicação e serviços. Os
usuários podem até mesmo gerenciar contêineres subjacentes, exibir logs para esses
contêineres e executar shell diretamente da interface do usuário.
 Rancher tem gerenciamento de credenciais nativo.
 Rancher pode fornecer acesso ao kubectl a partir da própria interface do usuário do Rancher.
 O balanceador de carga Rancher permite o roteamento de tráfego dos hosts para os
serviços e pods do Kubernetes
 Aplicativos complexos podem ser criados e publicados como modelos
Kubernetes para o catálogo do Rancher, permitindo que os usuários
implementem esses aplicativos com um único clique
2.4.1 Visualização da infra-estrutura
O Interface do Rancher fornece visibilidade completa sobre a infra-estrutura em que os
clusters Kubernetes estão em execução. O menu de infra-estrutura irá listar vários recursos
como mostrado abaixo:
A guia Hosts fornece visibilidade para todos os hosts, os contêineres executados nesses
hosts e seu status geral. Você pode editar rótulos(labels) de host editando definições de
host aqui.

Ao clicar em um host individual, você pode exibir informações detalhadas sobre o host:
A segunda parte da tela do host mostra detalhes sobre os conteiners em execução no host,
como seu local de armazenamento, etc.

A guia contêiner fornece informações para todos os contêineres no ambiente, incluindo os hosts
nos quais eles estão sendo executados, seus endereços IP e status:
No menu de contexto do lado direito, você pode executar o shell diretamente no contêiner em
execução e exibir os logs do conteiner:

Se clicar em qualquer contêiner único da lista, você verá informações detalhadas e vitais sobre
esse contêiner, como consumo de CPU, memória, rede e disco. Informações sobre
rótulos(labels), volumes e portas também são fornecidas na seção inferior. Esse nível de
detalhes e o acesso à infraestrutura básica fornecem uma maneira segura de acessar os hosts.
2.4.2 Operações CRUD para Kubernetes Baseado em interface
Nesta seção, criaremos um aplicativo de guestbook usando operações CRUD em objetos
Kubernetes. Usaremos o template de exemplo de aplicativo guestbook no catálogo da
comunidade do rancher.Mostraremos como criar um serviço e um controlador de replicação,
que pode ser usado como base para outros serviços e controladores de replicação.
Primeiro vá para o menu Kubernetes e selecione Serviços a partir daí:
Depois de selecionar "Adicionar Serviço", Você receberá uma área de texto onde você pode
colar/digitar a definição do Serviço.Você já recebeu um modelo para modificar. Depois de
clicar em Criar, o serviço será criado.

Você pode seguir passos semelhantes para criar um controlador de replicação (selecione
"Replication Controller" no menu suspenso Kubernetes). Você notará que no RC para o
frontend, definimos "réplicas: 3", o que se traduz em criar três pods:
Quando você cria o RC para redis-master, você notará que apenas um pod existe e está
usando um conteiner redis nomeado como mestre:

Depois de ter criado três Serviços e três RCs, você verá a pilha completa:
Há alguns pontos-chave a serem observados aqui:
 Havia três pods criados para o frontend, com base na definição RC. É uma prática
recomendada de Kubernetes não criar pods diretamente e criá-los somente através
dos RCs.
 Os três pods recebem três endereços IP de pod diferentes, mas um único endereço IP de HOST.
 Você também pode obter os detalhes de cada um dos contêineres que estão sendo
executados em um pod, juntamente com algumas informações básicas sobre seu
status.
Agora vamos para a página RC e clique no frontend RC. Tente excluir um pod como mostrado:

©Rancher Labs2016.Allrights Reserved. 20
Assim que você excluir um pod, outro será imediatamente criado.
Vamos ter certeza de que podemos acessar o serviço que acabamos de implementar. No
menu suspenso Kubernetes, você pode ir para Serviços, selecionar o serviço de frontend e
clicar na guia Portas. Você verá uma coluna para porta e NodePort. NodePort é a porta na
qual o serviço é exposto na máquina host.
2.4.3 Usando o kubectl - Gerenciamento de Credenciais e Acesso à Web
Rancher fornece uma forma baseada em interface de interagir com Kubernetes, que
complementa kubectl, a interface de linha de comando para Kubernetes. Rancher expõe
esta CLI através da interface; Ele pode ser acessado selecionando Kubectl no menu
suspenso Kubernetes. Você pode então executar comandos através do kubectl para obter
informações ou para alterar a configuração do cluster.

Você também pode gerar o arquivo de configuração do botão "Gerar config" no topo - e
junto com um executável local do kubectl, interagir com o cluster Kubernetes de sua
própria máquina.
Uma das coisas importantes a entender neste contexto é como seu acesso na interface afetará
o que você faz. Cada usuário em um ambiente Rancher é um "usuário" ou um "admin". Como
o nome sugere, o administrador tem todos os privilégios associados ao ambiente, enquanto os
usuários podem ser divididos em funções específicas (o mesmo usuário pode ter papéis(roles )
diferentes). A tabela a seguir explica quatro funções e seu nível de acesso dentro do ambiente.
Owner Member Restricted Read-Only
Operations on Stacks,
Services, and Catalog
Yes Yes Yes No
Operations on Hosts Yes Yes View Only View Only
Managing user access Yes No No No
2.4.4 Simplificando a Configuração de DNS com o Rancher DNS
Rancher vem com serviço de DNS interno que é uma substituição nativa para SkyDNS (um
serviço de DNS popular normalmente usado pelo cluster do Kubernetes). O serviço DNS é
executado dentro do conteiner "Rancher / agent-instance" juntamente com os serviços de
metadados do Rancher e o Rancher. Esse serviço DNS permite que contêineres dentro de um
ambiente conversem entre si e sua configuração é armazenada no arquivo
/var/lib/cattle/etc/cattle/dns/answers.json. O serviço DNS do Rancher permite a comunicação
entre serviços sem necessidade de

configuração. Vamos testar algumas coisas para entender como as entradas no arquivo
answers.json são atualizadas com base nas alterações.
Se você ainda tiver o aplicativo guestbook rodando no cluster Kubernetes, então o arquivo
answers.json terá uma entrada semelhante àquela abaixo para redis-master:
redis-master.default.svc.cluster.local.:
answer:
- "10.43.177.45"
Agora vamos excluir e recriar o serviço redis-master no console do Rancher. Assim que o
novo serviço estiver ativado, você poderá verificar no answer.json que a entrada foi atualizada:
redis-master.default.svc.cluster.local.:
answer:
- "10.43.136.181"
2.4.5 Gerenciar namespace Kubernetes
Namespaces são clusters virtuais em Kubernetes que podem se sentar em cima do mesmo
cluster físico. Eles fornecem separações lógicas entre equipes e seus ambientes, conforme
necessário. Rancher permite que você gerencie os namespaces diretamente da interface do
Rancher:
Você também pode adicionar namespaces com configuração YAML simples:

3 Implantando um aplicativo multi-service
3.1 Definindo Aplicações Multi-Service
No Capítulo 2, implementamos um aplicativo de guestbook para ilustrar as operações CRUD do
template guestbook que está aqui, Informações detalhadas e um exemplo de aplicação está
disponível aqui). Neste capítulo, cobrimos os detalhes de serviços, balanceamento de carga,
descoberta de serviço e, finalmente, persistência com o disco de nuvem, como o Google Cloud.
Você também pode olhar para outros exemplos, como WordPress com MySQL (Nível iniciante
e disponivel aqui), e um exemplo de pet store que é mais avançado e deve ser feito depois de
terminar este exercício básico (disponivel aqui).
A aplicação guestbook tem três componentes:
 Frontend: A UI que leva as entradas do usuário e persiste para Redis. Pode haver mais
de um nó para a carga do componente frontend balanceada por um balanceador de
carga
 Redis Master: O nó mestre de Redis usado para gravar dados do frontend. No
momento, Redis não suporta multi-master fora do servidor; Nós ficaremos com um nó
mestre único simples neste exemplo.
 Redis Slave: Redis slave é usado para ler dados pelo frontend. Nós vamos escalar isso
para dois nós assim um balanceador de carga será necessário.
3.2 Projetando um serviço kubernetes para um aplicativo
Os serviços são abstrações que escondem as alterações subjacentes nos pods. Vamos definir
um serviço para um objeto frontend e olhar para alguns aspectos importantes de como ele
afeta o comportamento.
apiVersion: v1
kind: Service
metadata:
name: frontend
labels:
name: frontend
spec:
type: NodePort
ports:
- port: 80
- protocol: “TCP”
- targetPort: 80
selector:
name: frontend
No primeiro bloco, definimos um serviço denominado "frontend": isto criará um objeto de
serviço em Kubernetes com um IP (normalmente referido como o IP de cluster). Para todos os
outros serviços, o IP do cluster é resolvido para o nome do serviço e o tráfego encaminhado
para os pods. Uma vez que o seletor para este serviço é "frontend", este serviço só irá
segmentar os pods que têm um rótulo de nome como frontend e estão executando na porta 80.
A expressão do seletor é avaliada continuamente e postada no objeto EndPoint dentro do
Kubernetes. Por exemplo, se escalarmos de dois pods para três, o tráfego será roteado para o
novo pod.

O targetPort é o mesmo que a porta se não for especificado, e o protocolo padrão for TCP;
Podemos omitir essas linhas se quisermos ficar com padrões. Um dos pontos-chave a entender
aqui é que "porta" se refere à porta exposta do Kubernetes, enquanto targetPort é a porta onde
o contêiner está escutando – mas none of these refer to port of host on which the pod is
running. If one service wants to talk to another service within Kubernetes cluster, the port of the
service will be used. But if you want the service to be exposed to the outside world we have to
use NodePort or LoadBalancer in “type” (Called ServiceType). If you don’t specify any value,
then the default value is ClusterIP, which allows connections only from within cluster.
NodePort proxies the port from service definition on the host andforwards all the traffic to intended
container and port. NodePort is chosen randomly from a pre-configured range, or can be specified
in the definition. The service is then available on each host on which a pod is running at NodePort.
NodePort can be used when you have only one node of a given component and don’t want to put
additional load balancer layer. NodePort is often used when you don’t want to use the load
balancer provided by the cluster, want to use an external one instead, or your cloud provider does
not fully support Kubernetes. The following screenshot shows the services and their type along
with other information.
You can also create services without a selector; this is done to abstract external services such as
a database or services in another Kubernetes namespace. Since the (pod) selector does not exist
in these cases, we have to manually create the EndPoint object so that the service refers to
external service. The service definition remains in same format except the selector block and
EndPoint declaration looks like thefollowing:
apiVersion: v1
kind: EndPoint
metadata:
name: frontend
subsets:
addresses:
ip: “192.168.17.99”
ports:
port: “8090”
3.3 Balanceamento de Carga usando os serviços de
balanceador de carga do Rancher
Construímos o serviço de frontend usando o NodePort na seção anterior; Agora vamos
construir o serviço usando o tipo LoadBalancer. A definição de serviço é a mesma exceto que
"tipo" tem valor de "Load Balancer". Uma vez que o serviço foi criado com sucesso, navegue
com o Rancher UI para o menu Kubernetes, selecione System e procure a seção "kubernetes-
loadbalancers". Você notará que um balanceador de carga foi criado:

Se você optar por editar o balanceador de carga, verá mais opções em sobre
dimensionamento, roteamento, etc. O balanceador de carga criado pelo rancher usa haproxy
e permite opções de configuração adicionais nas seções global e padrão.

Embora esse balanceador de carga tenha sido criado automaticamente como parte da
definição do serviço, podemos criar explicitamente um balanceador de carga e com opções
mais refinadas. A seção do sistema tem a opção de adicionar balanceador de carga:
Você pode executar um número fixo de contêineres do balanceador de carga ou pode optar por executar uma
instância do balanceador de carga em cada host. O número de instâncias do balanceador de carga deve ser
menor ou igual ao número de hosts para evitar conflito porta. Se você tentar criar mais balanceadores
de carga do que os hosts, o balanceador de carga aguardará que mais hosts apareçam e
estará ativando o estado até que mais hosts estejam disponíveis. Além disso, para o número
fixo de balanceadores de carga são afetados pelas regras de programação que iremos passar
em breve.
Rancher suporta balanceamento de carga L4 e encaminha as portas para destinos. Você pode
configurar várias portas e serviços e o balanceador de carga encaminhará o tráfego para uma
combinação de host e portas em um modo round robin.

O balanceador de carga também pode ser configurado como um balanceador de carga L7
definindo algumas opções avançadas. Se você não configurar as opções opcionais adicionais,
então ele vai funcionar como um L4 LB.
Na tela acima, podemos configurar diferentes nomes de host e caminhos de solicitação para
serem roteados para diferentes serviços de destino. Por exemplo, um pedido para
Rancher.Com pode ser roteado para um aplicativo da Web, enquanto Rancher.com/demo Pode
ser encaminhado para uma aplicação web completamente diferente. Até Mesmo um
wildcard(caractere curinga) por exemplo *.example.com pode ser usado para direcionar um
serviço. Uma vez que você pode definir várias regras - é possível que haja uma sobreposição
em regras de correspondência para solicitações de entrada e portanto a seguinte ordem de
precedência deve ser usada:
1. HOSTNAME SEM NENHUM WILDCARDS E URL
2. HOSTNAME SEM WILDCARDS
3. HOSTNAME COM WILDCARDS E URL
4. HOSTNAME WITH WILDCARDS
5. URL
6. DEFAULT (NO HOSTNAME, NO URL)
Como o balanceador de carga foi projetado como um balanceador de carga L4 e aprimorado
para ser um balanceador de carga L7, há uma captura que você deve ter em mente: se você
definir dois serviços (Vamos chamá-los S1 e S2) e duas portas de escuta (P1 e P2) então o
mapeamento será feito para todas as quatro combinações de serviços e portas (S1-P1, S1-P2,
S2-P1, S2-P2). Isto irá direcionar o tráfego do P1 para S2, ou inversamente, P2 para S1. Para
evitar isso, você precisará adicionar regras dummy como mostrado no exemplo abaixo
(mostrado para S1 na porta 81 e S2 na porta 80).
lb-test:
ports:
- 80:80
- 81:81
labels:
io.Rancher.loadbalancer.target.service1: 80=80
io.Rancher.loadbalancer.target.service1: dummy1:81=81
io.Rancher.loadbalancer.target.service2: 81=81
io.Rancher.loadbalancer.target.service2: dummy2:80=80

tty: true
image: Rancher/load-balancer-service
links:
- service1:service1
- service2:service2
stdin_open: true
Se você escolheu uma das portas de escuta para ser "SSL", então você tem opções para
escolher o certificado para o mesmo.
Se você deseja veicular tráfego de HTTP e HTTPS, isso pode ser conseguido usando duas
portas de escuta e mapeando o destino da porta verificada por SSL na porta HTTP:
O balanceador de carga também suporta persistência em pedidos usando cookie. Você pode
definir um cookie para todas as solicitações e respostas e pode ser personalizado com base nas
necessidades de persistência de sessão:

Labels(rótulos) e as rules(regras) de programação juntos fornecem uma maneira de controlar
quais hosts executarão o balanceador de carga. A capacidade de definir condições no host, no
contêiner e no nível de serviço permite definir políticas de agendamento muito finas no Rancher
(observe: se você tiver optado por executar apenas um container em cada host, verifique os
labels do host).
3.4 Descoberta de Serviço
Há duas formas do que o Kubernetes pode implementar descoberta de serviço:
através de variáveis de ambiente e através de DNS.
As variáveis de ambiente são definidas pela Kubernetes. Eles suportam Docker linking e
semântica simples como ${SERVICE_NAME}_SERVICE_HOST, etc. Por convenção, os
nomes são maiúsculas e os traços são convertidos em sublinhados. Se você executar “docker
inspect CONTAINER_ID” Em um dos contêiners, Você verá que muitas variáveis foram
definidas para o contêiner. Uma das deficiências com as variáveis de ambiente é que você tem
que manter sua ordem de criação. Uma vez que as variáveis de ambiente são definidas para o
contêiner, você precisará exibir primeiro um serviço dependente e em seguida o serviço usando
a variável de ambiente.
"Env": [
"KUBERNETES_PORT_443_TCP_PORT=443",
"FRONTEND_PORT_80_TCP_PORT=80",
"FRONTEND_PORT_80_TCP_PROTO=tcp",
"FRONTEND_PORT_80_TCP_ADDR=10.43.89.247",
"REDIS_MASTER_SERVICE_PORT=6379",
"REDIS_SLAVE_SERVICE_HOST=10.43.115.100",
"KUBERNETES_PORT=tcp://10.43.0.1:443",
"FRONTEND_PORT=tcp://10.43.89.247:80",
"REDIS_SLAVE_SERVICE_PORT=6379",
"REDIS_MASTER_PORT_6379_TCP=tcp://10.43.31.149:6379",
"REDIS_SLAVE_PORT=tcp://10.43.115.100:6379",
"REDIS_SLAVE_PORT_6379_TCP_ADDR=10.43.115.100",
"KUBERNETES_SERVICE_PORT=443",
"REDIS_MASTER_SERVICE_HOST=10.43.31.149",
"REDIS_SLAVE_PORT_6379_TCP_PROTO=tcp",
"REDIS_SLAVE_PORT_6379_TCP_PORT=6379",

"KUBERNETES_SERVICE_HOST=10.43.0.1",
Uma maneira mais limpa de implementar a descoberta do serviço é com o servidor DNS. Em
uma instalação do Kubernetes fora do Rancher, você terá que adicionar SkyDNS ou um serviço
semelhante como um add-on. Em um ambiente Rancher, o serviço DNS é incorporado (e
discutido brevemente na seção 2.4.4).
Novos registros são criados no DNS quando novos serviços e pods são iniciados e eles são
atualizados se esses pods ou serviços mudam. Um serviço é mapeado para seu IP de cluster e
cada serviço em um namespace é acessível diretamente a outros serviços. Se você quiser
acessar um serviço em um namespace diferente, isso pode ser feito com
<service_name>.<stack_name>
3.5 Storage
No exemplo acima, não usamos qualquer armazenamento persistente para armazenar dados
do Redis. Isso significa que os dados serão perdidos se o host reiniciar ou o contêiner for
deslocado para um novo host. Para tornar os dados acessíveis e persistentes entre os hosts,
precisamos usar algum tipo de disco persistente. Aqui, usaremos um disco para persistência no
Google Cloud Engine para o nosso aplicativo antes de discutir outras opções de
armazenamento.
Primeiro, o disco precisa ser criado explicitamente. Assumimos aqui que você configurou o
SDK do Google Cloud Engine em sua máquina e está conectado ao gcloud.
gcloud compute disks create --size=20GB --zone=$ZONE redis-disk
Certifique-se de que o host ao qual o disco será anexado tem as permissões apropriadas para
anexar e remover o disco. Uma vez que o disco está pronto, podemos mapeá-lo para o
contêiner (aqui, mostramos apenas a última parte de uma definição RC completa):
spec:
containers:
- name: master
image: redis
ports:
- containerPort: 6379
volumeMounts:
- name: redis-disk
mountPath: /data
volumes:
- name: redis-disk
gcePersistentDisk:
pdName: redis-disk
fsType: ext4
Conforme mostrado na configuração, mapeamos o contêiner de volume de dados / (onde Redis
armazena dados) para um disco persistente criado anteriormente. Com essa configuração, se o
host desligar e volta a iniciar, ou se movemos o container de um host para outro, os dados
ainda estarão persistidos.
Utilizamos o disco persistente do mecanismo de nuvem do Google neste exemplo, mas o
Kubernetes fornece mais alguns tipos de discos. A tabela abaixo fornece uma visão geral
rápida de algumas chaves de tipos de volume:

Volume Type Description
emptyDir Um diretório inicialmente vazio usado pelo container para armazenar
dados. Os dados persistem no host em falhas de contêiner, mas se o
pod for removido por algum motivo, os dados em emptyDir serão
excluídos.
hostPath Monta um diretório do host no container. Enquanto a maioria das
aplicações não iria querer usar isso, existem alguns casos úteis, por
exemplo, um contêiner executando cAdvisor pode montar e olhar
para /dev/cgroups
gcePersistentDisk Um disco de mecanismo de nuvem do Google que é desmontado
quando o contêiner é removido, mas pode ser re-montado enquanto
os dados persistirem. A gce PD também pode ser montada no modo
READ only em vários contêiners. O disco deve ser Criado/disponível
no google cloud engine antes de poder ser utilizado.
awsElasticBlockStore Semelhante ao gcePersistentDisk, persiste além do ciclo de vida do
contêiner. Deve ser criado antes de usar.
nfs Um servidor NFS que pode ser montado por vários containers. NFS
permite escrever em vários contêiners
Flocker Flocker é um gerenciador de volume de cluster de código aberto. Os
volumes do Flocker não estão ligados ao ciclo de vida do contêiner
ao qual estão montados; Os dados escritos para esses volumes
persistem além da vida útil do contêiner.
gitRepo Monta um diretório vazio e clona o conteúdo de um contêiner Git
nesse diretório. Especialmente útil quando você deseja buscar
arquivos de configuração ou padrão de um repositório.
Secret Secrets can be mounted as volumes (for example for passwords).
downloadAPI Monta um diretório vazio e, em seguida, copia os dados da API para
esse diretório em formato de texto sem formatação.
3.6 Secrets(Autentificação)
Em um grande cluster onde muitos dados de componentes sensíveis e o onde os componentes
de código podem estar em execução, É importante que os secrets e a autenticação sejam bem
gerenciados. Kubernetes fornece várias maneiras de gerenciar a autenticação entre sistemas.
Vamos criar um arquivo de secrets no contexto de nossa aplicação e liberar o acesso as
contas de serviço.
Criando Secrets
A maneira mais simples de criar secrets é usar a linha de comando kubectl e passar arquivos
que têm valor de nome de usuário e senha:
kubectl create secret generic redis-pass --from-file=./username.txt --from-file=./password.txt
O comando acima assume que username.txt tem nome de usuário e password.txt tem a senha.
O nome de usuário e senhas são codificados em B64 e armazenados no objeto chamado "
redis-pass" no caso acima. Também podemos codificar manualmente os valores de nome de
usuário/senha em b64 e então criar um objeto secret:
apiVersion: v1
kind: Secret
metadata:
name: redis-pass
type: Opaque

data:
password: c3VwZXJ0b3VnaHBhc3N3b3Jk
username: c3VwZXJ1c2Vy
Usando Secrets
Secrets podem ser usados como volumes de dados ou variáveis de ambiente dentro de um
pod. Um secret pode ser usado por mais de um serviço ou pod. Por exemplo, o pedaço de
código a seguir mostra como usar o segredo como uma variável de ambiente:
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
As contas de serviço são outra maneira de gerenciar a comunicação entre serviços ou pods e
são normalmente usadas para acessar um servidor de API para derivar o estado de
compartilhamento do cluster e interagir com o cluster. Por padrão, todas as chamadas
acontecem através de uma conta de serviço "padrão", mas contas de serviço adicionais podem
ser criadas. Tenha em mente que as contas de serviço destinam-se a componentes não-
humanos e não devem ser misturadas com contas de usuário reais criadas para que os
seres humanos acessem o cluster. Uma definição de conta de serviço tem esta aparência:
apiVersion: v1
kind: ServiceAccount
metadata:
name: elk
Na definição de um controlador de replicação, você pode especificar a conta de serviço a ser usada:
spec:
serviceAccount: elk
Você pode adicionar secrets à conta de serviço também (por exemplo, para buscar imagens do
Docker de um registro protegido ou para autenticar com determinados sistemas).

4 Operações de contêineres
4.1 Implantação Contínua - Upgrades de Serviço e Rollbacks
Em Kubernetes, há duas opções para implantações. Rolling-updates são um método mais
antigo de fazer implantações; Estes funcionam apenas com controladores de replicação.
Recomendamos o uso do novo objeto de Implantação para novas implantações de
aplicativos. Examinaremos rapidamente o método de atualização contínua e, em seguida,
abordaremos os objetos de implantação com mais detalhes.
Para o método rolling-update, primeiro crie um controlador de replicação com 4 réplicas e
nginx versão 1.7.9. Aguarde até que o controlador de replicação possa trazer todos os 4 pods:
apiVersion: v1
kind: ReplicationController
metadata:
name: my-nginx
spec:
replicas: 4
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
Assim que o RC estiver ativado, vamos para o console da web do kubectl em uma guia e
abrir a seção de controlador de replicação em outra guia do navegador.
kubectl rolling-update my-nginx –image=nginx:1.9.1
Você vai notar nos logs que Kubernetes decidiu implantar apenas um pod de cada vez,
e manteve um máximo de 5 pods a qualquer momento.
Se mudar para a UI do controlador de replicação no Rancher, você notará que criou um
novo controlador de replicação e está implantando novas imagens no novo RC.

À medida que a atualização avança, mais pods são adicionados ao novo controlador de
replicação e removidos do anterior:
Essencialmente, rolling-updates são uma maneira de atualizar um determinado número de
pods de cada vez movendo pods de um controlador de replicação para outro.
As implantações são o método recomendado para gerenciar atualizações de pods e
controladores de replicação. Com um objeto de implantação, você especifica apenas o
estado de destino a ser atingido e o controlador de implementação do Kubernetes
assegurará que o estado é alterado adequadamente. Especificar o estado desejado de
forma declarativa dá Implantações muita flexibilidade e poder. Por exemplo, Implantações
em Kubernetes são ótimas para os seguintes casos de uso:

(1) Para criar um novo controlador de replicação com seis nós de nginx, você pode usar
um Deployment e especificar o estado desejado
(2) Você pode verificar o status de uma implantação para seu sucesso ou para falhas
(3) Você pode reverter uma implantação anterior se a versão for encontrada instável
(4) Você pode pausar e retomar uma implantação - isso é especialmente executingcanary
canary deployments em que certos recursos são atualizados e em seguida, a
implantação é pausada. Se os resultados parecem positivos, então a implantação pode
ser retomada (caso contrário, eles podem serabortados).
(5) Você pode olhar para o histórico de implantação
Em primeiro lugar, examinaremos alguns casos de uso desta lista e, em seguida, alguns
parâmetros que podem ser ajustados para alterar o comportamento das implementações.
Primeiro, vamos criar uma implantação. Adicione um controlador de replicação e cole o
seguinte bloco. Observe que, uma vez que você cria uma Implantação a partir de uma das
opções, você não a verá na interface do usuário, mas poderá verificá-la a partir do console de
comandos kubectl. Contudo, Você verá os pods associados aparecer na interface do usuário à
medida que forem criados. Você pode manter uma guia aberta com o console de comando
kubectl monitorar as coisas à medida que elas acontecem.
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
Depois de criar a implantação usando a opção Adicionar serviço / RC, você pode ver a
implantação no kubectl:
Agora, vamos atualizar a implantação para uma versão superior do nginx. Observe que, uma
vez atualizado, você não consegue adicionar a mesma implantação na interface do usuário,
pois ela entrará em conflito com o nome anterior. Então vamos executar o seguinte comando
no kubectl:

kubectl edit deployment/nginx-deployment
Isso abrirá um editor dentro do console. Atualize a versão da imagem nginx de 1.7.9 para
1.9.1 e salve o arquivo. Depois de salvar, podemos assistir à Implantação para verificar como
a atualização está indo:
Também podemos verificar o histórico de controladores de replicação para ver como a
Implantação criou um novo controlador de replicação e desativou o antigo:
Podemos reverter para a versão anterior, uma vez que não fornecemos a flag "--record"
durante a execução de comandos - não vemos nada em " change-cause ".

O comando “kubectl describe deployments” vai lhe dar muito mais informações
sobre implantações.
4.1.1 Uma análise mais detalhada das implementações
Há alguns parâmetros no arquivo YAML de implantação, mas nesta seção vamos ver como
alguns dos parâmetros importantes dentro do arquivo de implantação podem ser modificados
para atender a diferentes requisitos.
Estratégia
O parâmetro de estratégia tem dois tipos: ReCreate e RollingUpdate. Sintaxe para o tipo de
estratégia, veja como abaixo:
.spec.strategy.type=Recreate
.spec.strategy.type=RollingUpdate
Recriar será, sem surpresa, recriar os pods existentes, matando, em seguida, reimplantando-
los. Da mesma forma, o RollingUpdate aplicará uma atualização contínua aos pods
existentes. Para RollingUpdates há parâmetros adicionais para controlar como as rolling
updates(atualizações continuas) são feias.
.spec.strategy.rollingUpdate.maxUnavailable
.spec.strategy.rollingUpdate.maxSurge
Para rolling updates, Apenas um certo número de pods são retirados e atualizados ao mesmo
tempo; Este processo é repetido até que todos os pods sejam atualizados. MaxUnavailable
especifica quantos pods podem estar desativados a qualquer momento durante uma
atualização. Isso pode ser um número absoluto, ou uma porcentagem de pods. O valor padrão
para MaxUnavailable é 1.

MaxSurge é outra opção que controla quantos pods podem ser criados a mais e o número
desejado a mais de pods.Semelhante a MaxUnavailable, este parâmetro pode ser definido
como um número absoluto ou como uma porcentagem e também é padrão para 1. Se
definimos MaxSurge e MaxUnavailable tanto para 20%, para dez pods, durante a implantação
Kubernetes será imediatamente escala de 12 pods no total E então 2 pods serão retirados da
pool mais antigo.
.spec.rollbackTo
.spec.rollbackTo.revision
rollbackTo contém a configuração para a qual o Implantação está sendo revertida. Definir
este campo fará com que um rollback e o campo será removido do objeto de implantação.
Você pode especificar ainda a exata "revision " para qual reversão deve ocorrer. O padrão é
considerado a última versão no histórico, mas a especificação de revision é útil em alguns
casos.
4.2 Rancher Private Registry Suporte para Kubernetes
In Rancher, you can configure private registries, and then use container images from those
registries for template definitions. Rancher supports Docker Hub, Quay.io or any other private
registry. You can also configure an insecure or internal certificate registry, though these require
bypassing a certificate check in Docker configuration files on all nodes. Each environment
requires its own registry assignment(s).
To add a new registry, go to Infrastructure  Registries. You will see if any registry is already
configured before adding a new one (adding a custom repository requires entering additional
information):
Once you have added a registry, you can access its container images with following format of
the image:
[registry-name]/[namespace]/[imagename]:[version]
By default, the repository is assumed to be Docker Hub. If you are using an image from Docker
Hub, you can use the short form of the above:

[imagename]:[version]
If a registry is insecure, you need to add an additional parameter in DOCKER_OPTS in the
Docker configuration file.:
DOCKER_OPTS="$DOCKER_OPTS --insecure-registry=${DOMAIN}:${PORT}"
If you are using a certificate with the repository that is internally signed, then you need to add
the certificate to certs.d directory of Docker and append the certificate to the certificate chain.
This will need to be completed for all hosts and requires a restart of Docker daemon:
# Download the certificate from the domain
$ openssl s_client -showcerts -connect ${DOMAIN}:${PORT} </dev/null 2>/dev/null|openssl x509 -
outform PEM >ca.crt
# Copy the certificate to the appropriate directories
$ sudo cp ca.crt /etc/Docker/certs.d/${DOMAIN}/ca.crt
# Append the certificate to a file
$ cat ca.crt | sudo tee -a /etc/ssl/certs/ca-certificates.crt
# Restart the Docker service to have the changes take affect
$ sudo service Docker restart
Once a registry is added, there are certain actions that can be done and it is important to
understand how it affects behavior.
 You can edit the registry to re-enter username, email or password
 You can deactivate a registry. After deactivation,
o No new images can be fetched from the deactivated registry (but images already
in use will continue to work).
o Any user who has access to the environment can re-activate a deactivated
registry without being asked for his or her password; if a registry should not be
re-activated, it’s best to delete it.
4.3 Monitoramento de contêineres
4.3.1 Monitoramento com Prometheus
Prometheus is a modern and popular monitoring and alerting system, built at SoundCloud and
eventually open sourced in 2012 – it handles multi-dimensional time series data really well. We
will deploy a full Prometheus suite to show you what all we can monitor in a Kubernetes cluster

using Prometheus. We will use the community template available here and deploy it using the
Rancher catalog. You can also check out detailed blog post on converting Cattle templates to
Kubernetes templates at Rancher blog here.
Below is a quick overview of how each component participates in monitoring:
 Prometheus: the core component that scrapes and stores data.
 Prometheus node exporter: gets host level metrics and exposes them to Prometheus.
 Ranch-eye: is an haproxy and exposes cAdvisor stats to Prometheus
 Grafana: visualization for data
 InfluxDB: time series database specifically used to store data from Rancher server which
is exported via the Graphite connector for Rancher.
 Prom-ranch-exporter: is a simple node.js application which helps in querying Rancher
server for states of a stack or service.
Once Prometheus has been successfully deployed, we can examine the various dashboards
available in Grafana to see what data is available. Note that you will have to use the IP for the
host where Grafana container is deployed and NodePort for the Grafana service. Grafana has
five distinct dashboards for different use case; let’s cover these one by one.
Container Stats
Container stats provides information on the host machines coming from cAdvisor and from the
Prometheus Rancher exporter.

Host Stats
The host stats dashboard shows the metrics related to the host, as gathered by Prometheus.

Prometheus Stats
The Prometheus Stats dashboard contains information about Prometheus itself, such as how
long the Prometheus service has been running, scrape duration, and more.
Rancher Stats
The Rancher Stats dashboard uses the Rancher graphite connector to provide information
about Rancher. Rancher graphite needs to be configured to point to the InfluxDB graphite host
and NodePort. Once this is done, you will need to restart the Rancher server. The metrics are
stored in Rancher DB in InfluxDB and then picked up by Grafana for visualization.

Stack Status – Prometheus
Stack status pulls information from the Rancher API about the health of individual containers.
4.4 Monitoring with Heapster
Heapster is a framework for monitoring and analyzing the performance of computing clusters, and
acts as an aggregator of performance data fetched from Kubernetes. It exposes a variety of
metrics at the node, container, pod, and namespace level through a REST endpoint. Heapster
natively supports Kubernetes and CoreOS, and a variety of backends can be used to store and
visualize the data. Data for all containers on a host is fetched by cAdvisor, which is then integrated
into a kubelet binary. The data is queried by Heapster and aggregated based on pods, services
etc. The data is then stored into one of the configured backends, such as InfluxDB.
We will use example from the Heapster repo here to deploy and monitor a Heapster cluster. You
can check out the details of all templates from the link; we will cover only some key points here.
Notice that the Heapster container takes its arguments for source and target based on where the
data will be stored.

spec:
containers:
- name: Heapster
image: kubernetes/Heapster:canary
imagePullPolicy: Always
command:
- /Heapster
- --source=kubernetes:https://kubernetes.default
- --sink=influxdb:http://monitoring-influxdb:8086
Change the “influxdb-grafana-controller.YAML” to use the following key-value pair (instead of
what is provided in the YAML file).
- name: GF_SERVER_ROOT_URL
value: /
Lastly, you will need to use a cloud provider or machines with publicly identifiable and reachable
hostnames, as Heapster uses publicly reachable hostnames from Kubernetes to reach the
nodes. Once you have setup Heapster, you will notice metrics will start flowing into the Grafana
UI.
4.5 Ingress Support
Typically, services and pods have IP addresses which are only reachable within the cluster. But
in many practical scenario, there is a need to provide an externally reachable URL or to provide
a virtual host based on name etc. Ingress are set of rules which enable incoming connections to
reach cluster services or pods. Ingress was introduced in Kubernetes 1.1 and in addition to an
ingress definition, you also need an ingress controller to satisfy those rules.
Imagine an ingress resource as set of rules, and the ingress controller as the engine which
satisfies those rules. Rancher comes with a built-in ingress controller and converts ingress rules
into load balancing functionality. Rancher listens to server events on Kubernetes, and creates
and updates the ingress controller accordingly. Let’s set up a simple ingress, and then explore
more complex use cases where ingress can be useful.
The first step is to create a service which we want to expose. Here we will use a simple nginx
container, and create a service and replication controller for it:

apiVersion: v1
kind: Service
metadata:
name: nginx-service
labels:
k8s-app: nginx-service
spec:
ports:
- port: 90
targetPort: 80
protocol: TCP
name: http
selector:
---
apiVersion: v1
metadata:
name: nginx-service
spec:
replicas: 1
selector:
template:
metadata:
labels:
spec:
terminationGracePeriodSeconds: 60
containers:
- name: nginx-service
image: nginx:latest
ports:
- containerPort: 80
This will simply create an nginx container, wrapped with a service. Note that with this
configuration, there is no way to access the service from outside of the cluster. To create, view,
and delete an ingress you will have to use kubectl command line. A sample ingress definition
looks like this:
kind: Ingress
metadata:
name: simplelb
spec:
rules:
- host: ingress.example.com ## The incoming host name
http:
paths:
- path: /test ## Path to service
backend:
serviceName: backend-service
servicePort: 90 ## service_port
In the above example, we have defined a single rule with a host, path and corresponding backend
serviceand port. Wecandefine multiple host and path combinations pointing to backend services.
For our nginx service, we will define simple ingress as shown in the code snippet below. Since
host is not specified, it defaults to an asterisk “*” and the path defaults to root path.

kind: Ingress
metadata:
name: simplelb
spec:
backend:
serviceName: nginx-service
servicePort: 90
Once you have created the ingress rule, you will notice that Rancher automatically creates a
corresponding load balancer. To view the load balancer, you can go to the Kubernetes System
view.
As you can see, a load balancer and appropriate routing has been created by Rancher based
on ingress rules definition. If we now click the Host IP at port 80, we can see the nginx
hompage:

4.5.1 Ingress Use cases
Host based routing
Multiple host URLs can be diverted to different services by defining ingress rules through a
single load balancer.
- host: foo.bar.com
http:
paths:
- backend:
serviceName: nginx-service-1
servicePort: 90
- host: bar.foo.com
http:
paths:
- backend:
servicePort: 90
Path based routing
Different paths of a service can be load-balanced with ingress rules:
spec:
rules:
- host: foo.bar.com
http:
paths:
- path: /foo
backend:
servicePort: 90
- path: /bar
backend:
servicePort: 90
Scaling ingress
In default configuration, the ingress rules definition will create a single load balancer on a single
host. You can use annotations to create multiple load balancers spread across multiple hosts
and using a non-default port. For the following example to work, you will need at least two
Kubernetes nodes with port 99 available:

kind: Ingress
metadata:
name: scaledlb
annotations:
scale: "2"
http.port: "99"
spec:
Ingress with TLS
Ingress can be also be set up with TLS. As a prerequisite, you will need to upload the certificate
in Rancher. You can then use TLS by specifying the port and the secretname in the tls field:
metadata:
name: tlslb
annotations:
https.port: "444"
spec:
tls:
- secretName: foo
backend:
4.6 Registo de contêiners
With large container deployments, it is important to collect log data from the containers for
analysis. The container logs might contain valuable information for finding the root cause of any
issues. In a Kubernetes cluster, there are a few functionalities required to build a logging platform:
 Collecting logs from containers running on a host
 Forwarding the logs to a central logging platform
 Formatting, filtering, analyzing and visualizating the logs.
There can be more areas in the platform such as alerting, monitoring etc. but we will not cover
those here.
For analysis and visualization, we will use the famous ELK (Elasticsearch, Logstash, Kibana)
stack. To collect and forward the logs to the logging platform, we will use LogSpout (though there
are other options like FluentD available).
If you are running Kubernetes on Google Cloud Platform, you also have the option of using Google
cloud logging services to analyze and visualize the logs (in addition to using the ELK stack on
Google Cloud).
4.6.1 Using ELK Stack and logspout
Let’s first set up a simple ELK cluster on Kubernetes. In the real world, Elasticsearch should be
set up with data, client and master as separate components so that they can be scaled easily
(there are templates and detailed documentation for Kubernetes here). For Logstash and Kibana,
we will use the images and templates developed by Paulo here with some minormodifications.
Let’s first create service for Elasticsearch. Note that we are creating the service in the “elk”
namespace.

apiVersion: v1
kind: Service
metadata:
name: elasticsearch
namespace: elk
labels:
component: elasticsearch
spec:
type: LoadBalancer
selector:
ports:
- name: http
port: 9200
protocol: TCP
- name: transport
port: 9300
protocol: TCP
Similarly, the replication controller is also created in the elk namespace.
apiVersion: v1
metadata:
name: es
namespace: elk
labels:
spec:
replicas: 1
template:
metadata:
labels:
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:
name: http
protocol: TCP
name: transport
protocol: TCP
volumeMounts:
- mountPath: /data
name: storage
volumes:
- name: storage
emptyDir: {}
As you may have noticed, we are using emptyDir type storage. This type is good for our quick
demo, but for real-world use cases, it is preferable to use persistent volumes.
The templates for Logstash and Kibana are very similar and you can check them out here.
However, let’s look at some of the important aspects before we launch the full stack:
For Kibana, we are provide the Elasticsearch URL as an environment variable:
- name: KIBANA_ES_URL
value: "http://elasticsearch.elk.svc.cluster.local:9200"
- name: KUBERNETES_TRUST_CERT
value: "true"
We are using a custom Logstash image, and again the Elasticsearch URL is provided as an
environment variable:
- name: ES_HOST_NAME
value: http://elasticsearch.elk.svc.cluster.local:9200
Onceall three containers are up and running you can do a quick verification with following checks
and confirm there are no issues in ELK setup.
 Elasticsearch will be reachable at container port 9200 and corresponding host/NodePort
combination if the stack has been set up correctly. You should see text similar to the one
below in response:
{
"status" : 200,
"name" : "Master Mold",
"cluster_name" : "myesdb",
"version" : {
"number" : "1.7.1",
"build_hash" : "b88f43fc40b0bcd7f173a1f9ee2e97816de80b19",
"build_timestamp" : "2015-07-29T09:54:16Z",
"build_snapshot" : false,
"lucene_version" : "4.10.4"
},
"tagline" : "You Know, for Search"
}

 Kibana UI will be reachable at container port 5601 and corresponding host/NodePort
combination. When you begin, there won’t be any data in Kibana (which is expected as
you have not pushed any data).
The next step is to set up the log aggregator from container hosts, and forward them to Logstash
for further processing. Here, we will use Logspout, a generic log forwarder. Logspout runs inside
a Docker container itself, and attaches to all containers running. The logs from all containers are
forwarded to the configured destination. In our case, the destination is Logstash so we will need
Logstash plugin. We have built a custom Docker image which has Logstash plugin baked in
(source code here). Logspout takes a parameter “ROUTE_URIS” which is where the logs are
routed to. Following is the template for the replication controller for LogSpout:
apiVersion: v1
metadata:
name: logspout
namespace: elk
labels:
component: elk
role: logspout
spec:
replicas: 1
selector:d
component: elk
role: logspout
template:
metadata:
labels:
component: elk
role: logspout
spec:
serviceAccount: elk
containers:
- name: logspout
image: infracloud/logspout-Logstash-docker
env:
- name: ROUTE_URIS
value: "Logstash://Logstash.elk.svc.cluster.local:5000"
volumeMounts:
- mountPath: "/var/run/docker.sock"
name: dockersock
volumes:
- hostPath:
path: "/var/run/docker.sock"
name: "dockersock"
For this to work, Logstash needs to be listening in on port 5000 with UDP. We have already put
this configuration into our Docker container for Logstash. Now you should see the following logs
in LogSpout pod:

And in Logstash:
Assuming all above steps succeeded, data should be flowing in Elasticsearch now. We can
verify this by looking at indexes of Elasticsearch:

The final step is to configure which indexes Kibana should look for in Elasticsearch. Once you
have configured the pattern with Logstash-*, you will see the log data trending in default
dashboard of Kibana:
What we have set up is a simple data pipeline, with all components required for aggregating,
logging, analyzing, and visualizing log data.
4.7 Auto Scaling
We can achieve auto scaling in Kubernetes in a Rancher environment using Kubernetes native
auto scaling.
In Kubernetes, manual scaling can be implemented using the “kubectl scale” command on
almost all resource types. Auto scaling in Kubernetes is achieved by using the Horizontal Pod
Autoscaling (HPA). Let’s take a closer look at how HPA works.
 HPA Prerequisites:
o HPA is triggered by pod CPU utilization.
o Heapster is required for querying CPUutilization
o The containers in the pod must have a CPU request set; HPA will not considering
the pods without a CPU request for auto scaling.
 Working
o HPA is designed as an API resource and controller – resource invokes actions
on controller and controller makes sure that target state is achieved.
o HPA watches CPU of pods at an interval which is controlled by parameter --
horizontal-pod-autoscaler-sync-period in controller manager.
o The actual CPU utilization is compared with the one requested by pod containers
based on algorithm here

o To change the state to desired state a new resource called “Scale” was
introduced. The scale resource can be queried for RC/deployment/Replica Setto
retrieve current number of resources and then send request to adjust desired
number of resources.
o Please note that some of these resource types and APIs were introduced in
versions as latest as 1.2 so the grouping of APIs might change in later versions.
 Via kubectl
o The auto scaling feature can also be interacted with by kubectl CLI. For example
to scale a replication controller named frontend when the CPU utilization hits
85%:
kubectl autoscale rc frontend --max=7 --cpu-percent=85
4.8 Kubernetes System Stack Upgrades in Rancher
If you look at the System menu in Kubernetes tab, you will see all containers which running in
the Kubernetes stack. This entire stack has been deployed via Rancher:
By clicking on the Compose YAML icon, you can also view the docker-compose and rancher-
compose files which together have created the Kubernetes stack:

As you can see, the containers used for the Kubernetes stack use specific versions of
Kubernetes and Rancher. For example, the controller-manager container uses
Rancher/k8s:v1.2.0-Rancher-1. If we want to upgrade this container to a newer version, we can
go to the context menu on right hand side, and choose upgrade (or simply click on upgrade
icon). We can upgrade the version of container and control certain options such as batch size
and the delay between batch upgrades.
The upgrade process creates a new version of the container and keeps it on standby until you
choose “Finish upgrade”. You can also rollback at this if the newer version has potential issues.

Let’s look at details of controller-manager – you will notice that there is one node running, one
stopped, and that the upgrade is waiting for confirmation on top right hand side. At this point, we
can inspect the logs to verify the upgrade and decide to upgrade or rollback.
If upgrade option is chosen – the new container will continue running and old one will be
discarded. If rollback is chosen, then the inverse happens: the new one is stopped and old one
is reinitialized.
If a container has a sidekick or data-container attached to it, you can choose to upgrade both of
them together too.
Although it is possible this way to upgrade individual components, it is not advisable to do so.
Starting with Rancher v1.1, Rancher provides an “Upgrade available” button right at top of
Kubernetes cluster when the upgrade is available:
You can choose the versions of Kubernetes and Rancher for the upgrade:

Rancher then will only upgrade components which have changed:
It is recommended to upgrade the entire Kubernetes stack through the upgrade menu, as this
method has been tested and verified to work with all components in the stack.

5 Building an Application Catalog
5.1 Rancher and Community Catalogs
Rancher provides a catalog of applications and platform stacks which can be deployed at click of
a button. An individual item in catalog is a template which defines collection of containers and
their configuration. A template for a given application should be self-sufficient in the sense that
provided all prerequisites are met (such as cloud disk) and once inputs are given at launch, it
should be able to launch the component/application completely. Rancher-certified templates are
maintained and supported by Rancher Labs, while community templates are maintained by the
open-source user community:
An admin can manage catalogs in Admin - Settings section. As an organization you can also
develop your own private catalogs, or supplement the community catalog to suit the needs of your
organization. The URL provided in additional catalog templates should work with “git clone”
command:

The catalog templates added here become available as options in the Rancher Catalog menu.
Here, we have enabled the “Rancher Certified” catalog, whose templates appear as “Library” in
catalog menu. We have also added a private catalog which is available with under the name
“infraCloud_Community”:
Rancher automatically syncs with the catalog repo for template updates.
5.2 One-Click Deployments for Kubernetes Applications
Let’s see how easy it is to deploy Kubernetes applications from Rancher. If you have enabled
the community catalog, you should see the template for the Ghost blogging platform available:

If you click on “View Details,” you will be shown versions available with some basic information:
You can configure additional parameters such as database credentials and launch:
You will notice associated services and pods being launched:

Once the containers are created and are available (as denoted with a green status checkmark),
you can hit the host-ip and NodePort to view the homepage for the blogging platform:
In a few minutes, we’ve launched a blogging platform with frontend and database components.
We could add scaling policies and launch this platform for multiple business units in a company if
need be; while this would require additional groundwork in creating Docker images for application
components and writing templates, but once this is done, launching and managing stacks is very
fast.

5.3 Creating New Kubernetes Catalog Templates
Now let’s cover writing templates for Kubernetes applications. At root of any Rancher Catalog
are four directories, corresponding to the frameworks natively supported by Rancher. Within the
kubernetes-templates directory, there are additional folders – one for each application or stack.
Let’s assume the name of our app is “App” and that it has two components (an application and a
database component).
Within the application directory, we can have more than one subdirectory, each representing a version of
the template. In our the directory above, versions 0 and 1 of the template are available. For each version,
you can have more than one service, replication controller, and pod definition YAML files. The Rancher-
compose.yml file contains basic information and input parameters needed by the application. For example:
.catalog:
name: app
version: 1.0
description: A test app
questions:
- variable: "mysql_root_pass"
label: "MySQL root password"
required: true
type: "password"
These input parameters can be used within templates with ${KEY_NAME}. The type of question here is
password but it can be any of string, enum, multiline or a certificate among other supported types. The
config.yml contains some basic information about app.
name: app-name
description: A test app
version: 1.0-Rancher1
category: Data
Finally the svg image used in app-name directory is the image which will show in the launch
icon.

6 Recursos adicionais
Documentation
o Kubernetes documentation: primary resource for Kubernetes concepts,
components, and best practices
o Rancher documentation: primary resource for Rancher concepts, components, and
best practices
Rancher Articles and Walkthroughs
The following articles, previously published on Rancher.com, may be of interest for users
interested in running containerized applications at scale, and making the most of Rancher’s
capabilities
o Launching Microservices Deployments on Kubernetes with Rancher: an
additional quick walkthrough on using Kubernetes with Rancher
o Converting a template from Cattle to Kubernetes: walks through the process of
taking a template used in Rancher’s Cattle framework, and making it easily
deployable in a Kubernetes environment.
o Rancher Controller for the Kubernetes Ingress Feature: An in-depth look on how
Rancher works with one of the key features of Kubernetes
o Creating a MongoDB Replica Set with the Rancher Kubernetes Catalog: a
walkthrough introduction to using replica sets and the Rancher Catalog.
Additional eBooks
o Building a CI/CD Pipeline with Rancher and Docker: a hands-on guidebook for
introducing containers into your build, test, and deployment processes

7 sobre os autores
Girish Shilamkar is the Founder and CEO of infraCloud Technologies. He has more than
decade of experience working in HPC Storage, Linux kernel, Cloud and DevOps domains. He
has worked in various roles like Kernel engineer, Apache CloudStack Committer, Storage
Architect and Cloud Architect. Girish worked on Distributed File Systems at CFS, Sun
Microsystems & Oracle during initial part of his career. Prior to starting infraCloud he was VP,
Engineering at Cloud solutions startup. He is deeply passionate about Distributed Systems,
Container Technology and Container Orchestration.
Vishal Biyani is Founder & CTO of infraCloud Technologies. His experience and expertise
lies in building highly scalable microservices based applications and infrastructure automation.
Throughout his career he has architected Cloud & DevOps solutions and also Big Data pipeline
solutions for large scale datacenters. Prior to infraCloud he has worked in companies like
AudienceScience, Nike, HCL and working complex infrastructure problems. Vishal is also an
avid blogger and was editor of SitePoint – publisher of technology content.
infraCloud Technologies is a programmable infrastructure company with leadership in building
highly scalable Container, Cloud & DevOps solutions

Implementando Kubernetes com Rancher

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Implementando Kubernetes com Rancher

Similaire à Implementando Kubernetes com Rancher (20)

Implementando Kubernetes com Rancher