StatefulSets

Diferença entre os tipos de aplicação:

STATE = estado

ex: uma aplicação de sessão do usuário. a aplicação depende dessa sessão e se cair em outra réplica

ele vai quebrar essa sessão, ele permite escalar horizontalmente?

FULL – depende totalmente do estado

LESS – não depende do estado

DESENHO [ ]

Neste caso utilizam o StickSession – Não fuinciona em aplicação que escala horizontalmente

Perguntas a se fazer pra rodar em cluster:

  • Como a aplicação gerencia a sessão de usuários?
  • Sistema de arquivos
  • Banco de dados

No caso de aplicação STATEFULL se faz necessário adaptar a aplicação para uso em cluster, um bom

exemplo é a aplicação que mantém a sessão do usuário utilizar um cache de chave/valor por exemplo

um Redis.

Introdução aos StatefulSets:

Objeto StatefulSet

passa pelo schaduler igual ao deployment mais com algumas particularidades

k get statefulset -A

caracteristicas:

  • deployment controlado – ex: banco de dados
  • nomes, ex: nginx-0, nginx-1, n ginx-2 (especificos e previsiveis )
  • volume por pod – 1 pvc pra cada pod
  • Headless svc – ??????

Deploy do local-path-provisioner

permite utilizar o storage de cada node (hd da maquina)

Utilizar a aplicação – rancher/local´path-provisioner

[github]

podemos instalar de varias formas até com HELM porém vamos utilizar de maneira simples pra exemplificar

e utilizando um conceito de usar o kubectl apply porém num manifesto remoto:

kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.23/deploy/local-path-storage.yaml

Cria:

  • namespace
  • serviceaccount
  • clusterrole.rbac
  • clusterrolebinding
  • deployment
  • storageclass
  • configmap
k get deploy -A
k get po 
k logs -n local-path-storage [pod]
k get storageclass -A

setar como default adicionar uma annotation:

k edit sc local-path
annotation:
  storageclass.kubernetes.io/is-default-class: "true"
k get sc

StatefulSets na Prática:

statefulset.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
k apply -f statefulser.yaml
k get po

(notar a ordem/sequencia da subida)

obs – o scale é mais lento por ser um pouco mais cadente

Volume Claim Templates: [link doc]

k explain statefulsets.spec.volumeClaimTemplates.spec
apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        volumeMounts:
          - name: nginx-html
            mountPath: "/usr/share/nginx/html"
volumeClaimTemplates:
  - metadata:
      name: nginx-html
    spec:
      accessModes: [ "ReadWriteOnce"]
      resources: 
        requests:
          storage: 1G
k get pvc -w (acompanhar a subida dos pvcs)

k apply -f statefulset.yaml

Pod Disruption Budget (pdb) – Garantindo a disponibilidade da aplicação:

Muito utilizado com aplicações Statefull utilizando stateFulSet – (single point failure)

É proteção contra um dreaning/ evicting [doc oficial]

k api-resources | grep disrups
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: nginx

executar a comando para verificar as labels dos pods que precisam ser adicionados do pdb

k get po --show-labels

verificar as opções que podemos adicionar :

k explain poddisruptionbudget.spec

teste: adicionar um maxunavailables: 0 e rodar

k drain worker-2 --ignore-damonsets
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  maxUnavailable: 0
  selector:
    matchLabels:
      app: nginx
plugins premium WordPress