[DAY9]k8s必学的设定档-yaml (下)

Deployment

在新版的 Kubernetes 官方推荐使用 Deployment 来取代 Replication Controller(rc)，两者间主要相同点包括确保处在服务状态的 Pod 数量(replicas)能满足先前所设定的值以及支援滚动升级(Rolling update)，前者额外支援回滚(Roll back)的机制，因此接下来会介绍如何利用 Deployment 来进行滚动升级。

资料来源

简单提一下为什麽k8s yaml中的kind是使用Deployment，而不是使用Pod呢。
虽然二者都可以把yaml部署到k8s上面，但是行为面来看还是有差异性的。
最直观的差异性

1.Deployment管理的对象是ReplicaSet，而ReplicaSet管理的对象是Pod
2.Deployment controller会去调度pod
3.对pod进行health check
4.pod坏掉时会监测到并进行重启
5.使用rolling update的方法更新pod，可以不停机的方式更新pod
6.根据使用资源(CPU/MEM)进行pod的自动扩充/缩减
用Pod就需要自行处理啦~~~
有Deployment没烦恼

推荐kubernetes deployment cheatsheet By jimmy song，有兴趣可以看看，那张图画的很棒rrrr
Deployment 结构示意图

Deployment yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-myapp
  labels:
    app: myapp
spec:
  replicas: 3  #定义pod的数量要几个，k8s会根据此设定值，维持pod数量
  template:    
    spec:
      containers:
        - name: myapp #container的名称
          image: myapp:latest #container image
          imagePullPolicy: Always #拉image的策略，分成Always,Nerver,IfNotPresent
          env: #环境变数
          - name: MY_ENV
            value: "12345"         
          ports: #container对外的port，如果服务本身除了http外还有grpc接口的需求，可以直接在里面加入另一种grpc的设定
            - name: http
              containerPort: 80 
              protocol: TCP #
            - name: grpc
              containerPort: 8787 
              protocol: TCP #
          readinessProbe: #检测container是否正常的探测设定
            httpGet: 
              path: "/healthcheck" #指定http route
              port: 80
            initialDelaySeconds: 2 #启动container延迟几秒後探测pod健康度
            periodSeconds: 5 #每几秒做一次
          command: ["./myapp", "start"] #启动成功後要执行的shell
          resources: #container的资源设定
            requests:
              cpu: 300m
      nodeSelector:
      

- imagePullPolicy :

- Always :每次都检查
- Nerver :不检查
- IfNotPresent :如果local有image就不检查，local没有时才pull image

• initialDelaySeconds:如果服务启动到http service能正常运作前就被进行health check的话，会让pod一直无限重启，因为对k8s来说，pod的health check fail就会重启pod，所以initialDelaySeconds的秒数要设定的比http service ready的时间要长一点。

- resources :

- `CPU`资源一般来说就是vCPU，大概就是1 thread,1000m = 1vCPU，如果node是4vCPU规格，对应就有4000m的cpu资源
- `Memory`这边是使用Mi(Megabyte)

- requests : limits控制上限，requests控制下限，如果没设定的话就让pod自由放飞XD，如果要设定HPA话，需要设定requests喔，HPA後面会再说明

requests:
  memory: "64Mi"
  cpu: "250m"
limits:
  memory: "128Mi"
  cpu: "500m"

如果pod资源超过设定值，有可能会发生以下情形就是了

• pod重启
• pod被驱逐(Eviction)，可以从kubectl get pods上面看到status会呈现Eviction
• pod被终止，但是有可能因为node资源都满载的情形下，就完全不会重启

这边有篇关於pod resources的文章，有兴趣可以看看
[Kubernetes] 分配 & 管理 container 所使用到的计算资源

nodeSelector : 将pod部署到特定的node上面，一般是使用label的方法搭配使用

参考资料来源

nodeSelector:
    kubernetes.io/os: linux #指定到k8s os为linux的node，如果cluster有多种os的node时，可以透过这个label去部署到linux的node上

因为本系列的部署是使用helm，所以就不会特别介绍kubectl的部署作法啦，下面是一些deployment的指令用法

# 建立deployment
kubectl create deployment <deployment_name> --image=<image>

# 更新deployment image版本
kubectl set image deployment/<deployment> <container-name>=image:<version>

# 检查deployment升级的历史记录
kubectl rollout history deployment/<deployment>

# 退版
kubectl rollout undo deployment/<deployment>

# 退到特定版本
kubectl rollout undo deployment/<deployment> --to-revision=2

# 重新启动deployment
kubectl rollout restart deployment/<deployment>

# 扩充到指定数量的pod
kubectl scale --replicas=5 deployment/<deployment>