k8s ----Explicação detalhada do controlador POD

O controlador de pod, também chamado de carga de trabalho, é a camada intermediária usada para gerenciar pods para garantir que os recursos do pod atendam ao status esperado. Quando um recurso do pod falhar, ele tentará reiniciar. Quando a política de reinicialização for inválida, os recursos do pod serão reiniciados. -criada.

2. tipo de controlador de pod

1. ReplicaSet: Cria um número especificado de cópias de pod em nome do usuário para garantir que o número de cópias de pod atenda ao status esperado e oferece suporte a funções automáticas de expansão e contração contínuas.
O ReplicaSet consiste principalmente em três componentes:
(1) O número de réplicas de pod esperado pelo usuário
(2) Seletor de rótulo para determinar qual pod é gerenciado por ele mesmo
(3) Quando o número de pods existentes for insuficiente, novos serão criados com base no modelo de recurso de pod
para ajudar os usuários a gerenciá-los. O status dos recursos de pod reflete com precisão o número de destino definido pelo usuário, mas RelicaSet não é um controlador usado diretamente, mas usa implantação.

2. Implantação : Funciona no ReplicaSet e é usado para gerenciar aplicativos sem estado. Atualmente é o melhor controlador. Suporta funções de atualização e reversão contínuas e também fornece configuração declarativa.
Os dois objetos de recurso ReplicaSet e Deployment substituem gradualmente a função anterior de RC.

3. DaemonSet : usado para garantir que cada nó no cluster execute apenas uma cópia específica do pod, geralmente usada para implementar tarefas em segundo plano no nível do sistema. Por exemplo,
recursos do serviço ELK: O serviço não tem estado e
deve ser um processo daemon

4. StatefulSet : Gerencie aplicativos com estado

5. Trabalho : Saia imediatamente assim que for concluído, sem necessidade de reiniciar ou reconstruir

6. Cronjob : Controle periódico de tarefas, sem necessidade de continuar executando em segundo plano

3. A relação entre Pod e controlador

controladores: objetos pod que gerenciam e executam contêineres no cluster. Os pods são associados por meio do seletor de rótulos.
O pod implementa a operação e manutenção do aplicativo por meio do controlador, como escalonamento, atualização, etc.

2: Implantação

部署无状态应用
管理Pod和ReplicaSet
具有上线部署、副本设定、滚动升级、回滚等功能
提供声明式更新，例如只更新一个新的image
应用场景：web服务

//示例：
vim nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx    
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80

kubectl create -f nginx-deployment.yaml

kubectl get pods,deploy,rs

//查看控制器配置
kubectl edit deployment/nginx-deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2021-04-19T08:13:50Z"
  generation: 1
  labels:
    app: nginx                    #Deployment资源的标签
  name: nginx-deployment
  namespace: default
  resourceVersion: "167208"
  selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deployment
  uid: d9d3fef9-20d2-4196-95fb-0e21e65af24a
spec:
  progressDeadlineSeconds: 600
  replicas: 3                    #期望的pod数量，默认是1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 25%                #升级过程中会先启动的新Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值
      maxUnavailable: 25%        #升级过程中在新的Pod启动好后销毁的旧Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值
    type: RollingUpdate            #滚动升级
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx                #Pod副本关联的标签
    spec:
      containers:
      - image: nginx:1.15.4                #镜像名称
        imagePullPolicy: IfNotPresent    #镜像拉取策略
        name: nginx
        ports:
        - containerPort: 80                #容器暴露的监听端口
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always                #容器重启策略
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
......

//查看历史版本
kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment
REVISION  CHANGE-CAUSE
1         <none>

Três:SatefulSet

部署有状态应用
稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
有序收缩，有序删除（即从N-1到0）

常见的应用场景：数据库
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # by default is 1
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

1. Composição StatefulSet

●Headless Service : usado para gerar registros DNS resolvíveis para identificadores de recursos de pod.
●volumeClaimTemplates (modelos de aplicação de volume de armazenamento) : Fornece armazenamento fixo exclusivo para recursos de Pod com base em métodos de fornecimento de PV estáticos ou dinâmicos.
●StatefulSet : usado para gerenciar e controlar recursos do Pod.

2. Por que deveríamos ficar sem cabeça?

Na implantação, cada pod não tem nome, é uma string aleatória e não é ordenado. Statefulset requer pedido e o nome de cada pod deve ser corrigido . Quando um nó falha, o identificador após a reconstrução permanece inalterado e o nome do nó de cada nó não pode ser alterado. O nome do pod é o identificador exclusivo usado para identificar o pod e seu identificador deve ser estável e exclusivo.
Para alcançar a estabilidade do identificador, é necessário um serviço headless para resolvê-lo diretamente para o pod, e um nome exclusivo precisa ser configurado para o pod.

3. Por que precisamos de volumeClaimTemplate?

A maioria dos conjuntos de réplicas com estado usa armazenamento persistente. Por exemplo, em sistemas distribuídos, porque os dados são diferentes, cada nó requer seu próprio nó de armazenamento dedicado. O volume de armazenamento criado no modelo de pod na implantação é um volume de armazenamento compartilhado. Vários pods usam o mesmo volume de armazenamento. No entanto, cada pod na definição statefulset não pode usar o mesmo volume de armazenamento. Portanto, um pod é criado com base no modelo de pod . Não é adequado, o que requer a introdução de volumeClaimTemplate. Ao usar statefulset para criar um pod, um PVC será gerado automaticamente, solicitando assim a vinculação de um PV para ter seu próprio volume de armazenamento dedicado.

Descoberta de serviço: É o processo de posicionamento mútuo entre serviços de aplicação.
Cenários de aplicação:
● Altamente dinâmico : os pods irão flutuar para outros nós
● Atualizações e lançamentos frequentes : o pensamento da Internet é executado em pequenos passos, implemente primeiro e depois otimize. O chefe sempre fica on-line primeiro e depois otimiza lentamente, e primeiro transforma a ideia em um produto para ganhar dinheiro Depois de ter o dinheiro, você pode otimizá-lo lentamente, pouco a pouco.
● Suporte ao escalonamento automático : quando houver uma grande venda, você definitivamente precisará expandir várias cópias.

O método de descoberta de serviço em K8S - DNS permite que o cluster K8S associe automaticamente o "nome" e o "CLUSTER-IP" do recurso Serviço, para que o serviço possa ser descoberto automaticamente pelo cluster.

4. Plug-in para implementar a função DNS no K8S

● skyDNS : versões anteriores ao Kubernetes 1.3
● kubeDNS : Kubernetes 1.3 a Kubernetes 1.11
● CoreDNS : Kubernetes 1.11 até o presente

5. Instale o CoreDNS. Somente o ambiente de implantação binário precisa instalar o CoreDNS.

方法一：
下载链接：https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/coredns/coredns.yaml.base

vim transforms2sed.sed
s/__DNS__SERVER__/10.0.0.2/g
s/__DNS__DOMAIN__/cluster.local/g
s/__DNS__MEMORY__LIMIT__/170Mi/g
s/__MACHINE_GENERATED_WARNING__/Warning: This is a file generated from the base underscore template file: coredns.yaml.base/g

sed -f transforms2sed.sed coredns.yaml.base > coredns.yaml

方法二：上传 coredns.yaml 文件

kubectl create -f coredns.yaml

kubectl get pods -n kube-system

vim nginx-service.yaml
apiVersion: v1  
kind: Service  
metadata:
  name: nginx-service
  labels:
    app: nginx  
spec:
  type: NodePort  
  ports:
  - port: 80
    targetPort: 80  
  selector:
    app: nginx

kubectl create -f nginx-service.yaml

kubectl get svc
NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP        5d19h
nginx-service   NodePort    10.96.173.115   <none>        80:31756/TCP   10s


vim pod6.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: dns-test
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4
    args:
    - /bin/sh
    - -c
    - sleep 36000
  restartPolicy: Never
  
kubectl create -f pod6.yaml

(1) Analisar nomes de kubernetes e serviços nginx

kubectl exec -it dns-test sh
/ # nslookup kubernetes
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local
/ # nslookup nginx-service
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      nginx-service
Address 1: 10.96.173.115 nginx-service.default.svc.cluster.local

(2) Veja a definição de statefulset

kubectl explain statefulset
KIND:     StatefulSet
VERSION:  apps/v1

DESCRIPTION:
     StatefulSet represents a set of pods with consistent identities. Identities
     are defined as: - Network: A single stable DNS and hostname. - Storage: As
     many VolumeClaims as requested. The StatefulSet guarantees that a given
     network identity will always map to the same storage identity.

FIELDS:
   apiVersion    <string>
   kind    <string>
   metadata    <Object>
   spec    <Object>
   status    <Object>

kubectl explain statefulset.spec
KIND:     StatefulSet
VERSION:  apps/v1

RESOURCE: spec <Object>

DESCRIPTION:
     Spec defines the desired identities of pods in this set.

     A StatefulSetSpec is the specification of a StatefulSet.

FIELDS:
   podManagementPolicy    <string>  #Pod管理策略
   replicas    <integer>    #副本数量
   revisionHistoryLimit    <integer>   #历史版本限制
   selector    <Object> -required-    #选择器，必选项
   serviceName    <string> -required-  #服务名称，必选项
   template    <Object> -required-    #模板，必选项
   updateStrategy    <Object>       #更新策略
   volumeClaimTemplates    <[]Object>   #存储卷申请模板，必选项

(3) Definição de lista StatefulSet

Conforme mencionado acima, um controlador StatefulSet completo consiste em um Headless Service, um StatefulSet e um volumeClaimTemplate. Conforme definido na lista de recursos abaixo:

vim stateful-demo.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
  labels:
    app: myapp-svc
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: myapp-pod
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: myapp
spec:
  serviceName: myapp-svc
  replicas: 3
  selector:
    matchLabels:
      app: myapp-pod
  template:
    metadata:
      labels:
        app: myapp-pod
    spec:
      containers:
      - name: myapp
        image: ikubernetes/myapp:v1
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: myappdata
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: myappdata
      annotations:          #动态PV创建时，使用annotations在PVC里声明一个StorageClass对象的标识进行关联
        volume.beta.kubernetes.io/storage-class: nfs-client-storageclass
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 2Gi

解析上例：由于 StatefulSet 资源依赖于一个实现存在的 Headless 类型的 Service 资源，所以需要先定义一个名为 myapp-svc 的 Headless Service 资源，用于为关联到每个 Pod 资源创建 DNS 资源记录。接着定义了一个名为 myapp 的 StatefulSet 资源，它通过 Pod 模板创建了 3 个 Pod 资源副本，并基于 volumeClaimTemplates 向前面创建的PV进行了请求大小为 2Gi 的专用存储卷。

(4) Criar PV

//stor01节点
mkdir -p /data/volumes/v{1,2,3,4,5}

vim /etc/exports
/data/volumes/v1 192.168.231.0/24(rw,no_root_squash)
/data/volumes/v2 192.168.231.0/24(rw,no_root_squash)
/data/volumes/v3 192.168.231.0/24(rw,no_root_squash)
/data/volumes/v4 192.168.231.0/24(rw,no_root_squash)
/data/volumes/v5 192.168.231.0/24(rw,no_root_squash)


systemctl restart rpcbind
systemctl restart nfs

exportfs -arv

showmount -e

(5) Definir PV

vim pv-demo.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
  labels:
    name: pv001
spec:
  nfs:
    path: /data/volumes/v1
    server: stor01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
  labels:
    name: pv002
spec:
  nfs:
    path: /data/volumes/v2
    server: stor01
  accessModes: ["ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
  labels:
    name: pv003
spec:
  nfs:
    path: /data/volumes/v3
    server: stor01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv004
  labels:
    name: pv004
spec:
  nfs:
    path: /data/volumes/v4
    server: stor01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv005
  labels:
    name: pv005
spec:
  nfs:
    path: /data/volumes/v5
    server: stor01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi


kubectl apply -f pv-demo.yaml

kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
pv001     1Gi        RWO,RWX        Retain           Available                                      7s
pv002     2Gi        RWO            Retain           Available                                      7s
pv003     2Gi        RWO,RWX        Retain           Available                                      7s
pv004     2Gi        RWO,RWX        Retain           Available                                      7s
pv005     2Gi        RWO,RWX        Retain           Available                                       7s

(6) Criar conjunto de estado

kubectl apply -f stateful-demo.yaml 

kubectl get svc  #查看创建的无头服务myapp-svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP             50d
myapp-svc    ClusterIP   None             <none>        80/TCP              38s

kubectl get sts    #查看statefulset
NAME      DESIRED   CURRENT   AGE
myapp     3         3         55s

kubectl get pvc    #查看pvc绑定
NAME                STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
myappdata-myapp-0   Bound     pv002     2Gi        RWO                           1m
myappdata-myapp-1   Bound     pv003     2Gi        RWO,RWX                       1m
myappdata-myapp-2   Bound     pv004     2Gi        RWO,RWX                       1m

kubectl get pv    #查看pv绑定
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                       STORAGECLASS   REASON    AGE
pv001     1Gi        RWO,RWX        Retain           Available                                                        6m
pv002     2Gi        RWO            Retain           Bound       default/myappdata-myapp-0                            6m
pv003     2Gi        RWO,RWX        Retain           Bound       default/myappdata-myapp-1                            6m
pv004     2Gi        RWO,RWX        Retain           Bound       default/myappdata-myapp-2                            6m
pv005     2Gi        RWO,RWX        Retain           Available                                                        6m

kubectl get pods   #查看Pod信息
NAME                     READY     STATUS    RESTARTS   AGE
myapp-0                  1/1       Running   0          2m
myapp-1                  1/1       Running   0          2m
myapp-2                  1/1       Running   0          2m


//当删除一个 StatefulSet 时，该 StatefulSet 不提供任何终止 Pod 的保证。为了实现 StatefulSet 中的 Pod 可以有序且体面地终止，可以在删除之前将 StatefulSet 缩容到 0。
kubectl scale statefulset myappdata-myapp --replicas=0
kubectl delete -f stateful-demo.yaml    

//此时PVC依旧存在的，再重新创建pod时，依旧会重新去绑定原来的pvc
kubectl apply -f stateful-demo.yaml

kubectl get pvc
NAME                STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
myappdata-myapp-0   Bound     pv002     2Gi        RWO                           5m
myappdata-myapp-1   Bound     pv003     2Gi        RWO,RWX                       5m
myappdata-myapp-2   Bound     pv004     2Gi        RWO,RWX

6. Atualização contínua

O controlador StatefulSet excluirá e recriará cada pod no StatefulSet. Ele procederá na mesma ordem do encerramento do pod (do maior ordinal para o menor ordinal), atualizando um pod por vez. Ele aguardará até que o status do pod sendo atualizado se torne Running e Ready antes de atualizar seu antecessor. A atualização contínua para a operação a seguir é atualizada na ordem de 2-0.

vim stateful-demo.yaml          #修改image版本为v2
.....
image: ikubernetes/myapp:v2
....

kubectl apply -f stateful-demo.yaml

kubectl get pods -w   #查看滚动更新的过程
NAME      READY   STATUS        RESTARTS   AGE
myapp-0   1/1     Running       0          29s
myapp-1   1/1     Running       0          27s
myapp-2   0/1     Terminating   0          26s
myapp-2   0/1     Terminating   0          30s
myapp-2   0/1     Terminating   0          30s
myapp-2   0/1     Pending       0          0s
myapp-2   0/1     Pending       0          0s
myapp-2   0/1     ContainerCreating   0          0s
myapp-2   1/1     Running             0          31s
myapp-1   1/1     Terminating         0          62s
myapp-1   0/1     Terminating         0          63s
myapp-1   0/1     Terminating         0          66s
myapp-1   0/1     Terminating         0          67s
myapp-1   0/1     Pending             0          0s
myapp-1   0/1     Pending             0          0s
myapp-1   0/1     ContainerCreating   0          0s
myapp-1   1/1     Running             0          30s
myapp-0   1/1     Terminating         0          99s
myapp-0   0/1     Terminating         0          100s
myapp-0   0/1     Terminating         0          101s
myapp-0   0/1     Terminating         0          101s
myapp-0   0/1     Pending             0          0s
myapp-0   0/1     Pending             0          0s
myapp-0   0/1     ContainerCreating   0          0s
myapp-0   1/1     Running             0          1s


//在创建的每一个Pod中，每一个pod自己的名称都是可以被解析的
kubectl exec -it myapp-0 /bin/sh
Name:      myapp-0.myapp-svc.default.svc.cluster.local
Address 1: 10.244.2.27 myapp-0.myapp-svc.default.svc.cluster.local
/ # nslookup myapp-1.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolve

Name:      myapp-1.myapp-svc.default.svc.cluster.local
Address 1: 10.244.1.14 myapp-1.myapp-svc.default.svc.cluster.local
/ # nslookup myapp-2.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolve

Name:      myapp-2.myapp-svc.default.svc.cluster.local
Address 1: 10.244.2.26 myapp-2.myapp-svc.default.svc.cluster.local

//从上面的解析，我们可以看到在容器当中可以通过对Pod的名称进行解析到ip。其解析的域名格式如下：
(pod_name).(service_name).(namespace_name).svc.cluster.local

7. Resumo

Sem estado
1) A implantação considera todos os pods iguais
2) Não há necessidade de considerar os requisitos do pedido
3) Não há necessidade de considerar em qual nó o nó está sendo executado
4) A capacidade pode ser expandida e reduzida à vontade

Stateful
1) Existem diferenças entre as instâncias, cada instância tem sua própria singularidade e metadados diferentes, como etcd, zookeeper
2) Relacionamentos assimétricos entre instâncias, bem como aplicativos que dependem de armazenamento externo.

8. A diferença entre serviço regular e serviço sem cabeça

serviço: um conjunto de políticas de acesso ao pod que fornecem comunicação entre clusters IP de cluster, bem como balanceamento de carga e descoberta de serviço.
Serviço headless: um serviço headless que não requer IP de cluster. Em vez disso, ele resolve diretamente o endereço IP do pod com proxy por meio de registros DNS.


vim pod6.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: dns-test
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4
    args:
    - /bin/sh
    - -c
    - sleep 36000
  restartPolicy: Never


vim sts.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1beta1  
kind: StatefulSet  
metadata:
  name: nginx-statefulset  
  namespace: default
spec:
  serviceName: nginx  
  replicas: 3  
  selector:
    matchLabels:  
       app: nginx
  template:  
    metadata:
      labels:
        app: nginx  
    spec:
      containers:
      - name: nginx
        image: nginx:latest  
        ports:
        - containerPort: 80  


kubectl apply -f sts.yaml

kubectl apply -f pod6.yaml

kubectl get pods,svc

kubectl exec -it dns-test sh
/ # nslookup nginx-statefulset-0.nginx.default.svc.cluster.local
/ # nslookup nginx-statefulset-1.nginx.default.svc.cluster.local
/ # nslookup nginx-statefulset-2.nginx.default.svc.cluster.local

kubectl exec -it nginx-statefulset-0 bash
/# curl nginx-statefulset-0.nginx
/# curl nginx-statefulset-1.nginx
/# curl nginx-statefulset-2.nginx

9. Expansão e contração

kubectl scale sts myapp --replicas=4  #扩容副本增加到4个

kubectl get pods -w  #动态查看扩容

kubectl get pv  #查看pv绑定

kubectl patch sts myapp -p '{"spec":{"replicas":2}}'  #打补丁方式缩容

kubectl get pods -w  #动态查看缩容

Quatro: DaemonSet

1、DaemonSet

DaemonSet garante que todos (ou alguns) nós estejam executando uma cópia do pod. Quando um Node se junta ao cluster, um Pod será adicionado a ele. Quando um Node é removido do cluster, esses Pods também serão reciclados. Excluir um DaemonSet excluirá todos os pods criados por ele.

Alguns usos típicos do DaemonSet :
●Execute o daemon de armazenamento em cluster, por exemplo, execute glusterd e ceph em cada nó.
●Execute o daemon de coleta de log em cada nó, como fluentd e logstash.
●Execute um daemon de monitoramento em cada nó, como Prometheus Node Exporter, collectd, agente Datadog, agente New Relic ou Ganglia gmond.
Cenário de aplicação: Agente
//Caso oficial (monitoramento)
https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

2. Estudo de caso

示例：
vim ds.yaml 
apiVersion: apps/v1
kind: DaemonSet 
metadata:
  name: nginx-daemonSet
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80


kubectl apply -f ds.yaml

//DaemonSet会在每个node节点都创建一个Pod
kubectl get pods
nginx-deployment-4kr6h   1/1     Running     0          35s
nginx-deployment-8jrg5   1/1     Running     0          35s

Cinco: Trabalho

O trabalho é dividido em tarefas comuns (Job) e tarefas agendadas (CronJob),
que são frequentemente usadas para executar tarefas que só precisam ser executadas uma vez.Cenários de
aplicação: migração de banco de dados, scripts em lote, verificação de banco de kube, processamento de dados offline, vídeo decodificação e outros serviços
https:// /kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

示例：
vim job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

//参数解释
.spec.template.spec.restartPolicy该属性拥有三个候选值：OnFailure，Never和Always。默认值为Always。它主要用于描述Pod内容器的重启策略。在Job中只能将此属性设置为OnFailure或Never，否则Job将不间断运行。

.spec.backoffLimit用于设置job失败后进行重试的次数，默认值为6。默认情况下，除非Pod失败或容器异常退出，Job任务将不间断的重试，此时Job遵循 .spec.backoffLimit上述说明。一旦.spec.backoffLimit达到，作业将被标记为失败。


//在所有node节点下载perl镜像，因为镜像比较大，所以建议提前下载好
docker pull perl

kubectl apply -f job.yaml 

kubectl get pods
pi-bqtf7                 0/1     Completed   0          41s

//结果输出到控制台
kubectl logs pi-bqtf7
3.14159265......

//清除job资源
kubectl delete -f job.yaml 

//backoffLimit
vim job-limit.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: busybox
spec:
  template:
    spec:
      containers:
        - name: busybox
          image: busybox
          imagePullPolicy: IfNotPresent
          command: ["/bin/sh", "-c", "sleep 10;date;exit 1"]
      restartPolicy: Never
  backoffLimit: 2
  
kubectl apply -f job-limit.yaml

kubectl get job,pods
NAME                COMPLETIONS   DURATION   AGE
job.batch/busybox   0/1           4m34s      4m34s

NAME                READY   STATUS   RESTARTS   AGE
pod/busybox-dhrkt   0/1     Error    0          4m34s
pod/busybox-kcx46   0/1     Error    0          4m
pod/busybox-tlk48   0/1     Error    0          4m21s

kubectl describe job busybox
......
Warning  BackoffLimitExceeded  43s    job-controller  Job has reached the specified backoff limit

Seis: CronJob

Tarefas periódicas, como o Crontab do Linux.
Cenários de aplicação de tarefas periódicas
: notificações, backups
https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/

示例：
//每分钟打印hello
vim cronjob.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure
          
//cronjob其它可用参数的配置
spec:
  concurrencyPolicy: Allow            #声明了 CronJob 创建的任务执行时发生重叠如何处理（并发性规则仅适用于相同 CronJob 创建的任务）。spec仅能声明下列规则中的一种:
                                         ●Allow (默认)：CronJob 允许并发任务执行。
                                         ●Forbid：CronJob 不允许并发任务执行；如果新任务的执行时间到了而老任务没有执行完，CronJob 会忽略新任务的执行。
                                         ●Replace：如果新任务的执行时间到了而老任务没有执行完，CronJob 会用新任务替换当前正在运行的任务。
  startingDeadlineSeconds: 15        #它表示任务如果由于某种原因错过了调度时间，开始该任务的截止时间的秒数。过了截止时间，CronJob 就不会开始任务，且标记失败.如果此字段未设置，那任务就没有最后期限。
  successfulJobsHistoryLimit: 3        #要保留的成功完成的任务数（默认为3）
  failedJobsHistoryLimit：1         #要保留多少已完成和失败的任务数（默认为1）
  suspend：true                     #如果设置为 true ，后续发生的执行都会被挂起。 这个设置对已经开始的执行不起作用。默认是 false。
  schedule: '*/1 * * * *'            #必需字段，作业时间表。在此示例中，作业将每分钟运行一次
  jobTemplate:                        #必需字段，作业模板。这类似于工作示例


kubectl create -f cronjob.yaml 

kubectl get cronjob
NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   */1 * * * *   False     0        <none>          25s

kubectl get pods
NAME                     READY   STATUS      RESTARTS   AGE
hello-1621587180-mffj6   0/1     Completed   0          3m
hello-1621587240-g68w4   0/1     Completed   0          2m
hello-1621587300-vmkqg   0/1     Completed   0          60s

kubectl logs hello-1621587180-mffj6
Fri May 21 09:03:14 UTC 2021
Hello from the Kubernetes cluster
//如果报错：Error from server (Forbidden): Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource=proxy) ( pods/log hello-1621587780-c7v54)
//解决办法：绑定一个cluster-admin的权限
kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous