Orquestrador de containers Docker.

Kubernetes Architecture

Pods é um “grupo de baleias” - Docker, certo? É a menor unidade de execução do Kubernetes. Dentro de um pod você pode ter um ou mais containeres.

  • Manifesto: é um ou mais arquivos yaml (ou json, mas não é mt usado) que define as configurações e estado de um pod.
    • Os tipos são definidos com o kind (Pods, Deployment, Service, etc)
    • Você pode usar a replicas para definir quantas instancias serão criadas.
    • A aplicação é definida pelo nome do container e a imagem que será usada

Helm: Encapsula os manifestos para permitir a criação dos pods. É um conjunto de manifestos.

https://artifacthub.io/ para instalar aplicaçães no Kubernetes de forma mais simples.

Os códigos yaml ficam armazenados em ferramentas de versionamento, como github, gitlab, Bitbucket, etc.

O ArgoCD irá ler o git para realizar o deploy.

As aplicações criadas são geradas e salvas em um Container Registry

Documentação de gerenciamento de imagens

Aplicações para aprender a usar localmente e testar em labs: Minikube e MicroK8s

Além das clouds padrões (GCP, AWS e Azure), é possível usar em locais como a Digital Ocean, Scaleway e Vultr, que são locais mais custo x benefício.

Para interagir com o cluster de Kubernetes, usamos o kubectl

O Kubernetes faz a separação lógica do cluster através dos namespaces. Para visualizar os namespaces, executamos o k get namespaces.

Dentro do manifesto, podemos criar um bloco que será responsável por realizar o Health Check do ambiente, permitindo inclusive que, em caso de falha, ele seja redirecionado para um outro nós. Um dos modos é chamado Liveness Probe

apiVersion: v1
kind: Pod
metadata:
  name: kuard
spec:
  containers:
    - image: gcr.io/kuar-demo/kuard-amd64:blue
      name: kuard
      livenessProbe:
        httpGet:
          path: /healthy
          port: 8080
        initialDelaySeconds: 5 # Seconds after all the containers in the pod are created
        timeoutSeconds: 1 # respond within the 1-second timeout
        periodSeconds: 10 # call the probe every 10 seconds
        failureThreshold: 3 # more than 3 consecutive probes fail, the container will fail and restart
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP

Quanto ao Resource Management, podemos especificar os requests e os limites de memória e/ou cpu que ele deve utilizar.

apiVersion: v1
kind: Pod
metadata:
  name: kuard
spec:
  containers:
    - image: gcr.io/kuar-demo/kuard-amd64:blue
      name: kuard
      resources:
        requests: # minimo que será solicitado
          cpu: "500m"
          memory: "128Mi"
        limits: # máximo que o container poderá consumir
          cpu: "1000m"
          memory: "256Mi"
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP

Para gerenciamento de estado, devemos criar os volumes

apiVersion: v1
kind: Pod
metadata:
  name: kuard
spec:
  volumes:
    - name:
      hostPath:
        path: /var/lib/kuard
  containers:
    - image: gcr.io/kuar-demo/kuard-amd64:blue
      name: kuard
      volumeMounts:
        - mountPath: "/data"
          name: "kuard-data"
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP

Para definir características de um pod, como dev e qa em um mesmo cluster, podemos usar os labels

apiVersion: v1
kind: Pod
metadata:
  name: kuard
  labels:
    environment: production
    app: nginx
    tier: frontend
  annotations:
    imageRegistry: "http://hub.docker.com"
spec:
  containers:
    - image: gcr.io/kuar-demo/kuard-amd64:blue
      name: kuard
      ports:
        - containerPort: 8080

Pod Controllers

São divididos em:

ConfigMaps & Secrets

ConfigMaps

https://kubernetes.io/docs/concepts/configuration/configmap/ É o desacoplamento de configurações para manter as imagens portáveis. Armazena dados não sensíveis em um par chave-valor

É um kind especial

apiVersion: v1
kind: ConfigMap
metadata: 
  name: game-demo
data:
  player_initial_lives: "3"
  ui_properties_file_name: "user-interface.properties"
  game.properties: |
    enemy.tyoes=aliens,monsters
    player.maximum-lives=5
  user-interface.properties: |
    color.good = purple
    color.bad = yellow
    allow.textmode = true

Secrets

https://kubernetes.io/docs/concepts/configuration/secret/ Armazena dados sensíveis como senhas, tokens ou chaves ssh. Usa encoding base64

apiVersion: V1
kind: Secret
metadata:
  name: sensitive-secret
  type: Opaque # Usa as chaves em base64. Olhar no link os outros diversos tipos de secret
  data:
    username: <nome do usuário convertido em base64>
    password: <senha convertida em base64>
    
---

apiVersion: V1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx
    env:
      - name: USERNAME
        valueFrom:
          secretKeyRef:
            name: sensitive-secret
            key: username
      - name: PASSWORD
        valueFrom:
          secretKeyRef:
            name: sensitive-secret
            key: password

Custom Controllers

É possível criar um kind próprio, criando o seu próprio operador. KOPF: Kubernetes Operators Framewok

Entender melhor sobre esse assunto e como criar esses operadores (e quando é necessário de fato).

Service Discovery

Tipos de serviços existentes:

Persistência de Dados

Statefulsets & Headless Services

Pod Names & Identity

Precisamos garantir a identidade dos pods, com isso, existem identidades já definidas e garantidas que terão o mesmo nome, em caso de queda, por exemplo.

Services

Criado principalmente em deployments de ambientes statefull, onde um SVC é o responsável por distribuir as cargas e identificar os pods de acordo com os nomes dados. Ele é quem garante a identidade na rede aos Pods.

Volume Claim Templates (VCT)

Vincula um volume a um container usando Statefulsets, com uma identidade Sticky

Volumes & Container Storage Interface (CSI)

Segue o mesmo conceito do Docker, gerencia volumes, porém esse volume aponta para um storage na nuvem, que pode estar em qualquer lugar.