Orquestrador de containers Docker.
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: TCPQuanto 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:
- DaemonSet
- https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
- Garante que todos os nós executarão uma cópia do Pod
- ReplicaSet
- https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
- Garante que um número pré determinado de pod estarão em execução
- Deployment
- https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
- Atualização do ReplicaSet, com melhorias e parâmetros melhores de uso
- StatefulSet
- https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
- Gerencia um conjunto de pods, garantindo ordenação e unicidade
- Job
- https://kubernetes.io/docs/concepts/workloads/controllers/job/
- Cria um ou mais Pods e garante que será finalizado após a execução
- Cronjob
- https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/
- Gerencia Jobs que devem ser executados ao longo do tempo, seguindo um schedule
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:
- Serviços:
- ClusterIP:
- https://kubernetes.io/docs/concepts/services-networking/service/#type-clusterip
- Serviço padrão, forncendo um IP interno.
- NodePort:
- https://kubernetes.io/docs/concepts/services-networking/service/#nodeport
- Não muito utilizados, por questões de segurança, uma vez que ele expoe portas do nós do cluster.
- Uso apenas para debugs específicos.
- Load Balancer:
- https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer
- O mais utilizado para produção, porém gera um custo considerável se você tiver diversas aplicações precisando do LB.
- Ingress:
- https://kubernetes.io/docs/concepts/services-networking/ingress/
- Modelo para múltiplas aplicações web, com um custo reduzido de infraestrutura.
- Te permite ter apenas um Load Balancer configurado e o serviço se responsabiliza pelo direcionamento interno de acordo com o endpoint acessado.
- ClusterIP:
- Network Security Policy:
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.