Na época deste artigo, Kubernetes tem cerca de seis anosde idade , e nos últimos dois anos, aumentou em popularidade para ser consistentemente uma das plataformas mais amadas. Este ano, ele vem como a plataforma número três mais amada. Se você ainda não ouviu falar sobre Kubernetes, é uma plataforma que permite que você execute e orquessine cargas de trabalho de contêineres.

Os contêineres começaram como uma construção de isolamento de processos de kernel Linux que abrange cgroups a partir de 2007 e namespaces a partir de 2002. Os contêineres tornaram-se mais uma coisa quando o LXC se tornou disponível em 2008, e o Google desenvolveu seu próprio “executar tudo em mecanismo de contêineres” chamado Borg. Avançamos para 2013, e Docker foi lançado e popularizou completamente os contêineres para as massas. Na época, Mesos era a principal ferramenta para orquestrar contêineres, no entanto, não foi tão amplamente adotado. Kubernetes foi lançado em 2015 e rapidamente se tornou o padrão de orquestração de contêineres de fato.

Para tentar entender a popularidade de Kubernetes, vamos considerar algumas perguntas. Quando foi a última vez que os desenvolvedores concordaram em como implantar aplicativos de produção? Quantos desenvolvedores você conhece que executam ferramentas como está fora da caixa? Quantos engenheiros de operações em nuvem hoje não entendem como funcionam as aplicações? Vamos explorar as respostas neste artigo.

 

Infraestrutura como YAML

 

Vindo do mundo de Puppet and Chef, uma das grandes mudanças com Kubernetes tem sido a mudança da infraestrutura como código para infraestrutura como dados — especificamente, como YAML. Todos os recursos em Kubernetes que incluem Pods, Configurações, Implantações, Volumes, etc., podem simplesmente ser expressos em um arquivo YAML. Por exemplo:

 

apiVersion: v1

 

kind: Pod

 

metadata:

 

name: site

 

labels:

 

app: web

 

spec:

 

containers:

 

– name: front-end

 

image: nginx

 

ports:

 

– containerPort: 80

Essa representação torna mais fácil para os DevOps ou engenheiros de confiabilidade do site expressar totalmente suas cargas de trabalho sem a necessidade de escrever código em uma linguagem de programação como Python, Ruby ou Javascript.

 

Outros benefícios de ter sua infraestrutura como dados incluem:

 

Controle de versão de operações git ou Git. Com esta abordagem, você pode manter todos os seus arquivos Kubernetes YAML sob repositórios git, o que permite que você saiba precisamente quando uma mudança foi feita, quem fez a mudança e o que exatamente mudou. Isso leva a mais transparência em toda a organização e melhora a eficiência, evitando a ambiguidade de onde os membros precisam ir para encontrar o que precisam. Ao mesmo tempo, pode facilitar a alteração automática dos recursos da Kubernetes apenas mesclando uma solicitação de tração.

Escalabilidade. Ter recursos definidos como YAML torna super fácil para os operadores de cluster alterar um ou dois números em um recurso Kubernetes para alterar o comportamento de escala. Kubernetes tem Autoscalers de pod horizontal para ajudá-lo a identificar um número mínimo e um número máximo de pods que uma implantação específica precisaria ter que ser capaz de lidar com tempos de tráfego baixos e altos. Por exemplo, se você estiver executando uma implantação que pode precisar de mais capacidade porque o tráfego aumenta repentinamente, você pode alterar maxReplicas de 10 para 20:

 

apiVersion: autoscaling/v2beta2

 

kind: HorizontalPodAutoscaler

 

metadata:

 

name: myapp

 

namespace: default

 

spec:

 

scaleTargetRef:

 

apiVersion: apps/v1

 

kind: Deployment

 

name: myapp-deployment

 

minReplicas: 1

 

maxReplicas: 20

 

metrics:

 

– type: Resource

 

resource:

 

name: cpu

 

target:

 

type: Utilization

 

averageUtilization: 50

 

Segurança e Controles. YAML é uma ótima maneira de validar o que e como as coisas são implantadas em Kubernetes. Por exemplo, uma das preocupações significativas quando se trata de segurança é se suas cargas de trabalho estão sendo executados como um usuário não raiz. Podemos fazer uso de ferramentas como conftest, um validador YAML/JSON, juntamente com o Open Policy Agent, um validador de políticas para verificar se o SecurityContext de suas cargas de trabalho não permite que um contêiner seja executado como uma raiz. Para isso, os usuários podem usar uma política simples do Agente de Política Aberta como esta:

 

package main

 

deny[msg] {

 

input.kind = “Deployment”

 

not input.spec.template.spec.securityContext.runAsNonRoot = true

 

msg = “Containers must not run as root”

 

}

 

Integrações de provedores em nuvem. Uma das principais tendências do setor de tecnologia é executar cargas de trabalho nos provedores de nuvem pública. Com a ajuda do componente do provedor de nuvem, a Kubernetes permite que cada cluster se integre ao provedor de nuvem em que está sendo executado. Por exemplo, se um usuário estiver executando um aplicativo em Kubernetes no AWS e quiser que esse aplicativo seja acessível através de um serviço, o provedor de nuvem ajuda a criar automaticamente um serviço LoadBalancer que irá automaticamente providenciar um Amazon Elastic Load Balancer para encaminhar o tráfego para os pods de aplicativos.

 

Extensibilidade

 

Kubernetes é muito extensível, e os desenvolvedores adoram isso. Existem um conjunto de recursos existentes como Pods, Implantações, StatefulSetsSecrets, ConfigMapsetc. No entanto, usuários e desenvolvedores podem adicionar mais recursos na forma de Definições de Recursos Personalizados. Por exemplo, se quisermos definir um recurso CronTab poderíamos fazê-lo com algo assim:

 

apiVersion: apiextensions.k8s.io/v1

 

kind: CustomResourceDefinition

 

metadata:

 

name: crontabs.my.org

 

spec:

 

group: my.org

 

versions:

 

– name: v1

 

served: true

 

storage: true

 

Schema:

 

openAPIV3Schema:

 

type: object

 

properties:

 

spec:

 

type: