No final do verão, queremos lembrar que continuamos trabalhando no tópico Kubernetes e decidimos publicar um artigo no Stackoverflow demonstrando o estado das coisas neste projeto no início de junho.

Gostar de ler!
No momento em que este livro foi escrito, o Kubernetes tinha cerca de seis anos e sua popularidade cresceu tanto nos últimos dois anos que sempre foi classificado entre as plataformas mais favorecidas . O Kubernetes está em terceiro lugar este ano. Como um lembrete, o Kubernetes é uma plataforma para executar e orquestrar cargas de trabalho em contêineres.
Os contêineres foram originados como uma construção especial para isolamento de processos no Linux; containers são cgroups desde 2007 e namespaces desde 2002. Os contêineres tomaram forma ainda melhor em 2008, quando o LXC foi disponibilizado e o Google desenvolveu seu próprio mecanismo interno chamado Borg.onde “todo o trabalho é feito em containers”. A partir daqui, avance para 2013, quando o primeiro lançamento do Docker ocorreu e os contêineres finalmente foram movidos para a categoria de soluções populares de massa. Naquela época, o Mesos era a principal ferramenta para orquestrar contêineres , embora não fosse muito popular. O primeiro lançamento do Kubernetes ocorreu em 2015, após o qual essa ferramenta se tornou o padrão de fato no campo da orquestração de contêineres.
Para tentar entender por que o Kubernetes é tão popular, vamos tentar responder a algumas perguntas. Quando foi a última vez que os desenvolvedores chegaram a um acordo sobre como implantar aplicativos para produção? Quantos desenvolvedores você conhece que usam ferramentas que são fornecidas fora da caixa? Quantos administradores de nuvem existem hoje que não entendem como os aplicativos funcionam? Consideraremos as respostas a essas perguntas neste artigo.
Infraestrutura como YAML
No mundo que foi de Puppet e Chef para Kubernetes, uma das maiores mudanças foi a mudança da infraestrutura como código para a infraestrutura como dados - especificamente como YAML. Todos os recursos no Kubernetes, que incluem pods, configurações, instâncias implantadas, volumes etc., podem ser facilmente descritos 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 visualização torna mais fácil para DevOps ou SREs expressarem totalmente suas cargas de trabalho sem ter que escrever código em linguagens como Python ou Javascript.
Outras vantagens de organizar a infraestrutura como dados, em particular, são as seguintes:
- GitOps Git Operations Version. YAML- Kubernetes git, , , , . , , , , . , Kubernetes – pull-.
- . YAML, Kubernetes, . Kubernetes , , , , . , , - , maxReplicas 10 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
- . YAML , Kubernetes. , , , , - , . conftest, YAML/JSON, Open Policy Agent, , , SecurityContext . , rego, :
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}
- . – . cloud-provider Kubernetes , . , Kubernetes AWS ,
LoadBalancer
, Amazon Elastic Load Balancer, .
O Kubernetes é muito extensível e os desenvolvedores adoram. Existe uma coleção de recursos disponíveis, como pods, sweeps,
StatefulSets
segredos ConfigMaps
, etc. No entanto, os usuários e desenvolvedores podem adicionar outros recursos na forma de definições de recursos personalizados .
Por exemplo, se quisermos definir um recurso
CronTab
, podemos fazer 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: object
properties:
cronSpec:
type: string
pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
replicas:
type: integer
minimum: 1
maximum: 10
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ct
Posteriormente, podemos criar um recurso CronTab mais ou menos assim:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Outra opção de extensibilidade no Kubernetes é que o desenvolvedor pode escrever seus próprios operadores. Um operador é um processo especial em um cluster Kubernetes que opera em um padrão de " loop de controle " . Com a ajuda de um operador, o usuário pode automatizar o gerenciamento de CRDs (definições de recursos personalizados) trocando informações com a API Kubernetes.
Existem várias ferramentas na comunidade que tornam mais fácil para os desenvolvedores criarem seus próprios operadores. Entre eles estão o Operator Framework e seu Operator SDK . Este SDK fornece uma estrutura a partir da qual um desenvolvedor pode começar a criar uma instrução muito rapidamente. Digamos que você possa começar na linha de comando mais ou menos assim:
$ operator-sdk new my-operator --repo github.com/myuser/my-operator
Isso cria todo o código estereotipado para o seu operador, incluindo os arquivos YAML e o código Golang:
.
|____cmd
| |____manager
| | |____main.go
|____go.mod
|____deploy
| |____role.yaml
| |____role_binding.yaml
| |____service_account.yaml
| |____operator.yaml
|____tools.go
|____go.sum
|____.gitignore
|____version
| |____version.go
|____build
| |____bin
| | |____user_setup
| | |____entrypoint
| |____Dockerfile
|____pkg
| |____apis
| | |____apis.go
| |____controller
| | |____controller.go
Em seguida, você pode adicionar as APIs e o controlador que desejar, como este:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService
A seguir, por fim, reúna a operadora e envie para o cadastro do seu container:
$ operator-sdk build your.container.registry/youruser/myapp-operator
Se o desenvolvedor precisar de ainda mais controle, você pode alterar o código estereotipado nos arquivos Go. Por exemplo, para modificar as especificações do controlador, você pode fazer alterações no arquivo
controller.go
.
Outro projeto, KUDO , permite criar instruções usando apenas arquivos YAML declarativos. Por exemplo, um operador para Apache Kafka seria definido de forma semelhante a isto . Com ele, você pode instalar um cluster Kafka em cima do Kubernetes com apenas alguns comandos:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafka
E então configure-o com outro comando:
$ kubectl kudo install kafka --instance=my-kafka-name \
-p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181 \
-p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m \
-p BROKER_COUNT=5 -p BROKER_MEM=4096m \
-p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3 \
-p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20
Inovação
Nos últimos anos, os principais lançamentos do Kubernetes foram lançados a cada poucos meses, ou seja, três a quatro lançamentos principais por ano. O número de novos recursos implementados em cada um deles não diminui. Além disso, não há sinais de desaceleração, mesmo em nossos tempos difíceis - veja a atividade atual do projeto Kubernetes no Github .
Novos recursos permitem operações de cluster com mais flexibilidade em uma variedade de cargas de trabalho. Além disso, os programadores gostam de mais controle ao implantar aplicativos diretamente na produção.
Comunidade
Outro aspecto importante da popularidade do Kubernetes é a força de sua comunidade. Em 2015, ao atingir a versão 1.0, o Kubernetes foi patrocinado pela Cloud Native Computing Foundation .
Há também uma variedade de comunidades SIG (grupos de interesse especial) para explorar diferentes áreas do Kubernetes conforme o projeto evolui. Essas equipes estão constantemente adicionando novos recursos para tornar o trabalho com o Kubernetes mais conveniente e conveniente.
A Cloud Native Foundation também está hospedando CloudNativeCon / KubeCon, que é a maior conferência de código aberto do mundo no momento em que este livro foi escrito. Normalmente, é realizado três vezes por ano e reúne milhares de profissionais que querem melhorar o Kubernetes e seu ecossistema, bem como novos recursos master que aparecem a cada três meses.
Além disso, a Cloud Native Foundation possui um Comitê de Supervisão Técnica , que, junto com SIGs, analisa projetos novos e existentes da fundação com foco no ecossistema de nuvem. A maioria desses projetos ajuda a melhorar os pontos fortes do Kubernetes.
Finalmente, acredito que o Kubernetes não teria tido tanto sucesso sem os esforços deliberados de toda a comunidade, onde as pessoas se apegam umas às outras, mas, ao mesmo tempo, aceitam de bom grado os recém-chegados em suas fileiras.
Futuro
Um dos principais desafios que os desenvolvedores terão de enfrentar no futuro é a capacidade de se concentrar nos detalhes do código em si, em vez da infraestrutura na qual ele opera. É a essas tendências que o paradigma da arquitetura sem servidor , que é um dos líderes hoje, responde . Já existem estruturas avançadas como Knative e OpenFaas que usam Kubernetes para abstrair a infraestrutura do desenvolvedor.
Neste artigo, vimos apenas o estado atual do Kubernetes - na verdade, isso é apenas a ponta do iceberg. Os usuários do Kubernetes têm muitos outros recursos, capacidades e configurações à sua disposição.