K8s não é a plataforma – ou é e todos nós entendemos mal?

Há apenas alguns anos, no palco principal da KubeCon North America, Kelsey Hightower falou sobre como o Kubernetes é apenas uma ferramenta de baixo nível e não uma plataforma (de desenvolvedor).

As empresas que construíssem plataformas internas para administrar seus negócios teriam que construir abstrações e máquinas acima do Kubernetes para reduzir a carga cognitiva dos desenvolvedores. Ainda mais, se bem feito, o Kubernetes se tornaria invisível e apenas um detalhe de implementação.

Para aqueles de nós que investimos profundamente no Kubernetes e no gigantesco ecossistema ao seu redor, esta última frase soa como um retrocesso. Se essa afirmação fosse verdadeira, estaríamos trabalhando para tornar os componentes invisíveis.

Agora, alguns anos depois, parece que todos nós entendemos mal. O Kubernetes está em toda parte e as pessoas estão construindo plataformas mais do que nunca com o Kubernetes como componente principal. Então, o que mudou? Vamos explorar onde chegamos e o que há de diferente hoje.

Da orquestração de contêineres a muito mais

Kubernetes era originalmente uma plataforma de orquestração de contêineres, construída principalmente para esse caso de uso único. Mas ao construir o orquestrador de contêineres mais avançado disponível na comunidade de código aberto, o projeto não terminou apenas com a orquestração de pods. Desde o início, o projeto incorporou pontos de extensão no sistema, principalmente definições de recursos personalizados (CRDs). Originalmente, os CRDs eram usados ​​para estender um cluster de computação com recursos auxiliares. Pense em recursos de configuração, CAs CertManager e CertificateRequests, camadas de rede de terceiros, como malhas de serviço. As possibilidades são infinitas e um ecossistema próspero evoluiu em torno da computação.

Mas as definições de recursos personalizados abriram as portas para muito mais. Muitos conceitos no Kubernetes não estão restritos à orquestração de contêineres. Quando questionados sobre o que provavelmente persistirá no Kubernetes por mais tempo, muitos líderes de pensamento concordam: o modelo de objeto, o modelo de servidor API CRUD altamente opinativo, provavelmente viverá por mais tempo.

O que isto significa? Isso significa que aprendemos muito mais do que como executar pods com mais eficiência desde que o Kubernetes 1.0 foi anunciado em 2015. As pessoas adoram a uniformidade das APIs que o Kubernetes oferece. As pessoas adoram poder usar uma ferramenta como kubectl para conversar com objetos muito diferentes, uma ferramenta GitOps falando a linguagem da API Kubernetes para implementar recursos muito diferentes, uma biblioteca de controlador como controller-runtime para construir loops de reconciliação para domínios muito diferentes. Você vê o padrão.

Todos nos lembramos das discussões sobre a construção de soluções em Kubernetes e a construção de APIs usando CRDs, onde surgiu a pergunta: Por que Kubernetes? Qualquer outra maquinaria API serviria. Isto é verdade, obviamente. Mas, ao mesmo tempo, você pode perguntar o inverso: por que não o Kubernetes e seu maquinário de API com seu rico ecossistema? Por que não deveríamos usar CRDs para construir, como plataformas de desenvolvedores?

Essa discussão é meio supérflua e rapidamente substituída pela realidade onde as pessoas estão fazendo exatamente isso. As pessoas adoram o ecossistema Kubernetes, as ferramentas construídas em torno de CRDs e APIs Kubernetes. Eles conhecem as ferramentas e sabem escrever controladores. A pergunta “O que mais?” é respondido simplesmente por “Kubernetes, porque temos o conhecimento, as ferramentas e somos produtivos com isso”. Além disso, há uma comunidade gigante em torno dela com a Cloud Native Computing Foundation e todos os seus projetos.

Vejamos como o Kubernetes ajuda a construir a plataforma que todas as empresas buscam hoje. No centro do Kubernetes está a API, uma API que permite o CRUD de objetos muito diversos, como gerenciar seu ciclo de vida de forma uniforme. O que queremos dizer com isso? O Kubernetes atende objetos (em todo o cluster e com espaçamento de nomes) chamados recursos. Os objetos têm uma forma comum que todos conhecemos:

```yaml
	kind:
	apiVersion:
	metadata:
	  name:
	  namespace:
	  labels:
	  annotations:
	  …
	spec:
	  …
	status:
	  …
	```

Esse formato comum possibilita soluções universais, como soluções para GitOps que funcionam com todos os tipos de recursos oferecidos por um cluster Kubernetes. Se nossa plataforma de desenvolvedor falar a linguagem das APIs Kubernetes, todas essas ferramentas funcionarão e poderão imediatamente fazer parte de nossa caixa de ferramentas.

Tradicionalmente, os recursos do Kubernetes eventualmente precisam de código real, geralmente código Golang. Embora os CRDs possam ser definidos declarativamente com várias linhas YAML, a lógica real requer programação real. Programação significa custo, manutenção e muito mais. Geralmente é o que os construtores de plataformas evitam em vez de adotar.

Entrar no plano cruzado

O modelo de objeto Kubernetes pode oferecer suporte a outras maneiras de definir lógica para implementação de APIs. O projeto Crossplane é um ótimo exemplo. Crossplane, outro projeto CNCF, nasceu em 2018 a partir da percepção de que a API Kube é perfeitamente adequada para orquestrar recursos arbitrários em nuvem. Um ou dois anos após o início do projeto, um conceito chamado Composições foi inventado. As composições implementam um padrão sem uma única linha de código que todos conhecemos do Kubernetes: pense em implantações, ReplicaSets e pods. Eles formam uma hierarquia: as implantações geram ReplicaSets e os ReplicaSets geram pods. As composições implementam esse tipo de hierarquia que define como uma instância se desdobra em outros objetos do Kubernetes.

Uma plataforma de desenvolvedor precisa de abstrações de nível superior para minimizar a carga cognitiva dos desenvolvedores. Uma implantação é uma abstração de pods. Em uma plataforma de desenvolvedor, pense em um aplicativo BigCorp, uma abstração que a BigCorp deseja oferecer aos seus desenvolvedores: altamente opinativa, altamente customizada para BigCorp, toda baseada em API. Crossplane torna muito fácil definir tal abstração sem uma única linha de código:

```yaml
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata: 
  name: xapplication.bigcorp.com
spec:
  group: bigcorp.com
  names:
    kind: XApplication
    plural: xapplications
  claimNames:
    kind: Application
    plural: applications
  versions:
  - name: v1
    schema: ... # an OpenAPI CRD schema
    storage: true
```

Uma definição de recurso composto (XRD abreviado) define uma definição de recurso personalizada com semântica composta. Concretamente, um objeto Composition define como um objeto de declaração Application (com namespace) gera um XApplication, gerando mais recursos quando instanciado:

```yaml
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: xapplication-webapp
spec:
  compositeTypeRef:
    apiVersion: bigcorp.com/v1
    kind: XApplication
  resources:
  - name: database
    base:
      apiVersion: sql.gcp.crossplane.io/v1beta1
      kind: Database
      spec:
        ...
  - name: ingress
    base:
      apiVersion: kubernetes.crossplane.io/v1beta1
      kind: Object
      spec:
        forProvider:
          manifest:
            apiVersion: networking.k8s.io/v1
            kind: Ingress
            spec:
              rules:
              - http: 
                ...
  - name: deployment
    base:
      apiVersion: kubernetes.crossplane.io/v1beta1
      kind: Object
      spec:
        forProvider:
          manifest:
      apiVersion: apps/v1
      kind: Deployment 
      spec:
        template:
          ...
```

Imagine um desenvolvedor na BigCorp usando esta API criando uma instância para o novo aplicativo de feedback do cliente ser implantado em um subdomínio do site da empresa:

```yaml
apiVersion: bigcorp.com/v1
kind: Application
metadata:
  name: customer-feedback
  namespace: marketing-team
spec:
  domain: feedback.bigcorp.com
	```

A Definição de Recursos Compostos (XRD) define o esquema desta API. A composição xapplication-webapp define em quais recursos isso se desdobra e como o valor do domínio especificado eventualmente termina na definição de entrada (por meio de Patch e Transformações, muito parecido com modelos).

A composição especifica dois objetos normais do Kubernetes neste exemplo, mas também um recurso de infraestrutura para um banco de dados de provedor de nuvem. Os recursos do Kubernetes podem chegar ao mesmo cluster do Kubernetes que a própria declaração ou ser distribuídos para outros clusters, como o cluster de produção de aplicativos us-east1 ou outro na Europa.

Observe que o aplicativo customer-feedback/marketing-team é apenas mais um objeto da API Kubernetes, compatível com todas as ferramentas disponíveis no ecossistema. Por exemplo, a equipe da plataforma deseja definir barreiras sobre o que esse desenvolvedor pode fazer com um aplicativo. Escolha um entre Kyverno, OpenPolicyAgent ou jsPolicy. A equipe financeira deseja reduzir os gastos com nuvem e agregar custos aos objetos Aplicativo da BigCorp para tornar os custos visíveis para o proprietário do aplicativo? Escolha OpenCost ou KubeCost. E assim por diante.

O desenvolvedor, com todas essas ferramentas de plataforma instaladas, usará kubectl ou a ferramenta GitOps de sua escolha para criar a declaração do aplicativo BigCorp:

```shell
$ kubectl apply -f customer-feedback-app.yaml
```

Para o Kubernetes, este é apenas mais um recurso: o Kubernetes gerenciará seu ciclo de vida, definirá a semântica de sua API, etc. Para Crossplane, esta é uma instância do xapplication-webapp composição. Crossplane sabe da Composição e XRD acima como dar vida à afirmação:

• Crossplane criará um composto XApplication.
• Ele selecionará o xapplication-webapp composição para o XApplication como implementação.
• Ele irá desdobrar o XApplication em um banco de dados, o objeto de entrada e implantação de acordo com a composição selecionada.
• Ele criará o banco de dados SQL no provedor de nuvem de sua escolha.
• Ele implantará os objetos Kubernetes no mesmo cluster ou em clusters de produção de sua escolha.
• Ou criará outro cluster dedicado com Argo CD como a ferramenta GitOps preferida, automaticamente instalada e conectada ao repositório git do seu aplicativo.
• Ele registrará a aplicação e as dependências especificadas na instância Backstage da empresa.
• Ele observará o status de todas essas etapas e reportará ao desenvolvedor o status do objeto BigCorp Application.
• Ele gerenciará o ciclo de vida de todos os recursos criados.
• Isso destruirá tudo quando o desenvolvedor decidir excluir o aplicativo.

Tudo isso acontece sem código. Isso acontece no Kubernetes e possivelmente envolve vários clusters do Kubernetes. Ele está implementando uma parte de uma plataforma de desenvolvedor. A plataforma do desenvolvedor não é Kubernetes no sentido das abstrações que o Kube fornece como orquestrador de contêineres. Mas a plataforma do desenvolvedor é construída com base na tecnologia Kubernetes e na linguagem das APIs e controladores do Kubernetes. Ele implementa abstrações de alto nível. Isso dá à BigCorp um kit de ferramentas de blocos de construção e um ecossistema rico.

O Kubernetes oferece computação apenas como um efeito colateral. O aplicativo BigCorp pode optar por implantar em algum outro serviço de computação, por exemplo, criando um lambda.aws.crossplane.io/v1beta1 object para o aplicativo de feedback do cliente em vez de uma implantação do Kubernetes. A computação é apenas uma parte da plataforma do desenvolvedor e potencialmente invisível para o desenvolvedor. A computação é apenas uma parte do Kubernetes, o potencial que tem como base para resolver problemas reais de negócios.

Então onde estamos hoje? Kubernetes e ferramentas como Crossplane nos fornecem uma caixa de ferramentas poderosa para construir plataformas. Kubernetes não é a plataforma. Nós entendemos mal o que isso significa. A orquestração de contêineres Kubernetes não é uma “plataforma como está” para desenvolvedores e pode até ser invisível ou não ser utilizada. Mas o Kubernetes como tecnologia é maior e se tornou a linguagem preferida para construir plataformas.

Junte-se a nós na KubeCon + CloudNativeCon North America em novembro. 6-9 em Chicago para saber mais sobre Kubernetes e o ecossistema nativo da nuvem.

O post K8s não é a plataforma – ou é e todos nós entendemos mal? apareceu primeiro em The New Stack.