K8S-pod控制器
目录：
对外
node ip +service
ingress+service
负载均衡抓包，然后看nodeIP(node ip +service)，再查看Cluster IP（有端口），查看ip在端点上（看能不能访问可以curl），如果能看到但是访问不了，可以干掉service重建就行
无状态：数据之间不互相同步
有状态：数据之间需要同步，是需要加存储的
获取一个deployment资源的配置模板
1、kubectl create deployment <资源名称> --image=<镜像> [--port= --replicas= ]
--dry-run=client -oyaml > 文件名
2、结合kubectl explain deployment 查看字段，硬敲
3、kubectl get deployment <资源名称> -oyaml >文件名
4、在官网找案例，复制粘贴
5、kubectl edit deployment <资源名称>，复制粘贴
无头headless service就是无cluster ip的service，一种特殊的service
有状态就是不变的名称(即无头模式)来绑定ip
有状态：
headless service 是没有IP的
statefulset 5 pod 创建
即从0到N-1 启动 有序 一个一个 部署
删除是倒叙
Pod控制器及其功用
Pod控制器，又称之为工作负载（workload），是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试进行重启，当根据重启策略无效，则会重新新建pod的资源。
pod控制器有多种类型：
1、ReplicaSet: 代用户创建指定数量的pod副本，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能。
ReplicaSet主要三个组件组成：
（1）用户期望的pod副本数量
（2）标签选择器，判断哪个pod归自己管理
（3）当现存的pod数量不足，会根据pod资源模板进行新建
帮助用户管理无状态的pod资源，精确反应用户定义的目标数量，但是RelicaSet不是直接使用的控制器，而是使用Deployment。
2、Deployment：工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。
ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用。
3、DaemonSet：用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如ELK服务
特性：服务是无状态的
服务必须是守护进程
4、StatefulSet：管理有状态应用
5、Job：只要完成就立即退出，不需要重启或重建
6、Cronjob：周期性任务控制，不需要持续后台运行
//Pod与控制器之间的关系
controllers：在集群上管理和运行容器的 pod 对象， pod 通过 label-selector 相关联。
Pod 通过控制器实现应用的运维，如伸缩，升级等。
1、Deployment
部署无状态应用
管理Pod和ReplicaSet
具有上线部署、副本设定、滚动升级、回滚等功能
提供声明式更新，例如只更新一个新的image
应用场景：web服务
1 vim nginx-deployment.yaml 2 apiVersion: apps/v1 3 kind: Deployment 4 metadata: 5 name: nginx-deployment 6 labels: 7 app: nginx 8 spec: 9 replicas: 3 10 selector: 11 matchLabels: 12 app: nginx 13 template: 14 metadata: 15 labels: 16 app: nginx 17 spec: 18 containers: 19 - name: nginx 20 image: nginx:1.15.4 21 ports: 22 - containerPort: 80 23 kubectl create -f nginx-deployment.yaml 24 kubectl get pods,deploy,rs 25 //查看控制器配置 26 kubectl edit deployment/nginx-deployment 27 apiVersion: apps/v1 28 kind: Deployment 29 metadata: 30 annotations: 31 deployment.kubernetes.io/revision: "1" 32 creationTimestamp: "2021-04-19T08:13:50Z" 33 generation: 1 34 labels: 35 app: nginx #Deployment资源的标签 36 name: nginx-deployment 37 namespace: default 38 resourceVersion: "167208" 39 selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deployment 40 uid: d9d3fef9-20d2-4196-95fb-0e21e65af24a 41 spec: 42 progressDeadlineSeconds: 600 43 replicas: 3 #期望的pod数量，默认是1 44 revisionHistoryLimit: 10 45 selector: 46 matchLabels: 47 app: nginx 48 strategy: 49 rollingUpdate: 50 maxSurge: 25% #升级过程中会先启动的新Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值 51 maxUnavailable: 25% #升级过程中在新的Pod启动好后销毁的旧Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值 52 type: RollingUpdate #滚动升级 53 template: 54 metadata: 55 creationTimestamp: null 56 labels: 57 app: nginx #Pod副本关联的标签 58 spec: 59 containers: 60 - image: nginx:1.15.4 #镜像名称 61 imagePullPolicy: IfNotPresent #镜像拉取策略 62 name: nginx 63 ports: 64 - containerPort: 80 #容器暴露的监听端口 65 protocol: TCP 66 resources: {} 67 terminationMessagePath: /dev/termination-log 68 terminationMessagePolicy: File 69 dnsPolicy: ClusterFirst 70 restartPolicy: Always #容器重启策略 71 schedulerName: default-scheduler 72 securityContext: {} 73 terminationGracePeriodSeconds: 30 74 ...... 75 //查看历史版本 76 kubectl rollout history deployment/nginx-deployment 77 deployment.apps/nginx-deployment 78 REVISION CHANGE-CAUSE 79 1 <none> 80 2、SatefulSet
部署有状态应用
稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
有序收缩，有序删除（即从N-1到0）
1 常见的应用场景：数据库 2 https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/ 3 apiVersion: v1 4 kind: Service 5 metadata: 6 name: nginx 7 labels: 8 app: nginx 9 spec: 10 ports: 11 port: 80 12 name: web 13 clusterIP: None 14 selector: 15 app: nginx
1 // 2 pod怎么调用server：通过名称 3 // 4 apiVersion: apps/v1 5 kind: StatefulSet 6 metadata: 7 name: web 8 spec: 9 selector: 10 matchLabels: 11 app: nginx # has to match .spec.template.metadata.labels 12 serviceName: "nginx" 13 replicas: 3 # by default is 1 14 template: 15 metadata: 16 labels: 17 app: nginx # has to match .spec.selector.matchLabels 18 spec: 19 terminationGracePeriodSeconds: 10 20 containers: 21 - name: nginx 22 image: k8s.gcr.io/nginx-slim:0.8 23 ports: 24 - containerPort: 80 25 name: web 26 volumeMounts: ##容器挂载目录 27 - name: www 28 mountPath: /usr/share/nginx/html 29 volumeClaimTemplates: ##与无状态的区别之一：存储 30 metadata: 31 name: www ##名称要与上面的一样 32 spec: 33 accessModes: [ "ReadWriteOnce" ] 34 storageClassName: "my-storage-class" #对应的是存储插件 35 resources: 36 requests: 37 storage: 1Gi
从上面的应用场景可以发现，StatefulSet由以下几个部分组成：
●Headless Service（无头服务）：用于为Pod资源标识符生成可解析的DNS记录。
●volumeClaimTemplates（存储卷申请模板）：基于静态或动态PV供给方式为Pod资源提供专有的固定存储。
●StatefulSet：用于管控Pod资源。
为什么要有headless？
在deployment中，每一个pod是没有名称，是随机字符串，是无序的。而statefulset中是要求有序的，每一个pod的名称必须是固定的。当节点挂了，重建之后的标识符是不变的，每一个节点的节点名称是不能改变的。pod名称是作为pod识别的唯一标识符，必须保证其标识符的稳定并且唯一。
为了实现标识符的稳定，这时候就需要一个headless service 解析直达到pod，还需要给pod配置一个唯一的名称。
大部分有状态副本集都会用到持久存储，比如分布式系统来说，由于数据是不一样的，每个节点都需要自己专用的存储节点。而在 deployment中pod模板中创建的存储卷是一个共享的存储卷，多个pod使用同一个存储卷，而statefulset定义中的每一个pod都不能使用同一个存储卷，由此基于pod模板创建pod是不适应的，这就需要引入volumeClainTemplate，当在使用statefulset创建pod时，会自动生成一个PVC，从而请求绑定一个PV，从而有自己专用的存储卷。
服务发现：就是应用服务之间相互定位的过程。
应用场景：
●动态性强：Pod会飘到别的node节点
●更新发布频繁：互联网思维小步快跑，先实现再优化，老板永远是先上线再慢慢优化，先把idea变成产品挣到钱然后再慢慢一点一点优化
●支持自动伸缩：一来大促，肯定是要扩容多个副本
K8S里服务发现的方式---DNS，使K8S集群能够自动关联Service资源的“名称”和“CLUSTER-IP”，从而达到服务被集群自动发现的目的。
实现K8S里DNS功能的插件：
●skyDNS：Kubernetes 1.3之前的版本
●kubeDNS：Kubernetes 1.3至Kubernetes 1.11
●CoreDNS：Kubernetes 1.11开始至今
仅二进制部署环境需要安装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 文件
1 kubectl create -f coredns.yaml 2 3 kubectl get pods -n kube-system 4 5 6 vim nginx-service.yaml 7 apiVersion: v1 8 kind: Service 9 metadata: 10 name: nginx-service 11 labels: 12 app: nginx 13 spec: 14 type: NodePort 15 ports: 16 - port: 80 17 targetPort: 80 18 selector: 19 app: nginx 20 21 kubectl create -f nginx-service.yaml 22 23 kubectl get svc 24 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 25 kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 5d19h 26 nginx-service NodePort 10.96.173.115 <none> 80:31756/TCP 10s 27 28 29 vim pod6.yaml 30 apiVersion: v1 31 kind: Pod 32 metadata: 33 name: dns-test 34 spec: 35 containers: 36 - name: busybox 37 image: busybox:1.28.4 38 args: 39 - /bin/sh 40 - -c 41 - sleep 36000 42 restartPolicy: Never 43 44 kubectl create -f pod6.yaml
实验和解释
动态的pvc通过storageclass绑定pv，storageclass通过里面插件pervisioner在nfs创建对应路径并跟pv关联
1 kubectl exec -it dns-test sh 2 / # nslookup kubernetes 3 Server: 10.96.0.10 4 Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local 5 6 Name: kubernetes 7 Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local 8 / # nslookup nginx-service 9 Server: 10.96.0.10 10 Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local 11 12 Name: nginx-service 13 Address 1: 10.96.173.115 nginx-service.default.svc.cluster.local
查看statefulset的定义
1 kubectl explain statefulset 2 KIND: StatefulSet 3 VERSION: apps/v1 4 5 DESCRIPTION: 6 StatefulSet represents a set of pods with consistent identities. Identities 7 are defined as: - Network: A single stable DNS and hostname. - Storage: As 8 many VolumeClaims as requested. The StatefulSet guarantees that a given 9 network identity will always map to the same storage identity. 10 11 FIELDS: 12 apiVersion <string> 13 kind <string> 14 metadata <Object> 15 spec <Object> 16 status <Object> 17 18 kubectl explain statefulset.spec 19 KIND: StatefulSet 20 VERSION: apps/v1 21 22 RESOURCE: spec <Object> 23 24 DESCRIPTION: 25 Spec defines the desired identities of pods in this set. 26 27 A StatefulSetSpec is the specification of a StatefulSet. 28 29 FIELDS: 30 podManagementPolicy <string> #Pod管理策略 31 replicas <integer> #副本数量 32 revisionHistoryLimit <integer> #历史版本限制 33 selector <Object> -required- #选择器，必选项 34 serviceName <string> -required- #服务名称，必选项 35 template <Object> -required- #模板，必选项 36 updateStrategy <Object> #更新策略 37 volumeClaimTemplates <[]Object> #存储卷申请模板，必选项
清单定义StatefulSet
如上所述，一个完整的 StatefulSet 控制器由一个 Headless Service、一个 StatefulSet 和一个 volumeClaimTemplate 组成。如下资源清单中的定义：
1 vim stateful-demo.yaml 2 apiVersion: v1 3 kind: Service 4 metadata: 5 name: myapp-svc 6 labels: 7 app: myapp-svc 8 spec: 9 ports: 10 - port: 80 11 name: web 12 clusterIP: None 13 selector: 14 app: myapp-pod 15 --- 16 apiVersion: apps/v1 17 kind: StatefulSet 18 metadata: 19 name: myapp 20 spec: 21 serviceName: myapp-svc 22 replicas: 3 23 selector: 24 matchLabels: 25 app: myapp-pod 26 template: 27 metadata: 28 labels: 29 app: myapp-pod 30 spec: 31 containers: 32 - name: myapp 33 image: ikubernetes/myapp:v1 34 ports: 35 - containerPort: 80 36 name: web 37 volumeMounts: 38 - name: myappdata 39 mountPath: /usr/share/nginx/html 40 volumeClaimTemplates: 41 - metadata: 42 name: myappdata 43 annotations: #动态PV创建时，使用annotations在PVC里声明一个StorageClass对象的标识进行关联 44 volume.beta.kubernetes.io/storage-class: nfs-client-storageclass 45 spec: 46 accessModes: ["ReadWriteOnce"] 47 resources: 48 requests: 49 storage: 2Gi
解析上例：由于 StatefulSet 资源依赖于一个实现存在的 Headless 类型的 Service 资源，所以需要先定义一个名为 myapp-svc 的 Headless Service 资源，用于为关联到每个 Pod 资源创建 DNS 资源记录。接着定义了一个名为 myapp 的 StatefulSet 资源，它通过 Pod 模板创建了 3 个 Pod 资源副本，并基于 volumeClaimTemplates 向前面创建的PV进行了请求大小为 2Gi 的专用存储卷。
创建pv
1 //stor01节点 2 mkdir -p /data/volumes/v{1,2,3,4,5} 3 4 vim /etc/exports 5 /data/volumes/v1 192.168.80.0/24(rw,no_root_squash) 6 /data/volumes/v2 192.168.80.0/24(rw,no_root_squash) 7 /data/volumes/v3 192.168.80.0/24(rw,no_root_squash) 8 /data/volumes/v4 192.168.80.0/24(rw,no_root_squash) 9 /data/volumes/v5 192.168.80.0/24(rw,no_root_squash) 10 11 12 systemctl restart rpcbind 13 systemctl restart nfs 14 15 exportfs -arv 16 17 showmount -e
定义PV
1 vim pv-demo.yaml 2 apiVersion: v1 3 kind: PersistentVolume 4 metadata: 5 name: pv001 6 labels: 7 name: pv001 8 spec: 9 nfs: 10 path: /data/volumes/v1 11 server: stor01 12 accessModes: ["ReadWriteMany","ReadWriteOnce"] 13 capacity: 14 storage: 1Gi 15 --- 16 apiVersion: v1 17 kind: PersistentVolume 18 metadata: 19 name: pv002 20 labels: 21 name: pv002 22 spec: 23 nfs: 24 path: /data/volumes/v2 25 server: stor01 26 accessModes: ["ReadWriteOnce"] 27 capacity: 28 storage: 2Gi 29 --- 30 apiVersion: v1 31 kind: PersistentVolume 32 metadata: 33 name: pv003 34 labels: 35 name: pv003 36 spec: 37 nfs: 38 path: /data/volumes/v3 39 server: stor01 40 accessModes: ["ReadWriteMany","ReadWriteOnce"] 41 capacity: 42 storage: 2Gi 43 --- 44 apiVersion: v1 45 kind: PersistentVolume 46 metadata: 47 name: pv004 48 labels: 49 name: pv004 50 spec: 51 nfs: 52 path: /data/volumes/v4 53 server: stor01 54 accessModes: ["ReadWriteMany","ReadWriteOnce"] 55 capacity: 56 storage: 2Gi 57 --- 58 apiVersion: v1 59 kind: PersistentVolume 60 metadata: 61 name: pv005 62 labels: 63 name: pv005 64 spec: 65 nfs: 66 path: /data/volumes/v5 67 server: stor01 68 accessModes: ["ReadWriteMany","ReadWriteOnce"] 69 capacity: 70 storage: 2Gi 71 72 73 kubectl apply -f pv-demo.yaml 74 75 kubectl get pv 76 NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE 77 pv001 1Gi RWO,RWX Retain Available 7s 78 pv002 2Gi RWO Retain Available 7s 79 pv003 2Gi RWO,RWX Retain Available 7s 80 pv004 2Gi RWO,RWX Retain Available 7s 81 pv005 2Gi RWO,RWX Retain Available 7s
1 // 2 kubectl apply -f stateful-demo.yaml 3 4 kubectl get svc #查看创建的无头服务myapp-svc 5 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 6 kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 50d 7 myapp-svc ClusterIP None <none> 80/TCP 38s 8 9 kubectl get sts #查看statefulset 10 NAME DESIRED CURRENT AGE 11 myapp 3 3 55s 12 13 kubectl get pvc #查看pvc绑定 14 NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE 15 myappdata-myapp-0 Bound pv002 2Gi RWO 1m 16 myappdata-myapp-1 Bound pv003 2Gi RWO,RWX 1m 17 myappdata-myapp-2 Bound pv004 2Gi RWO,RWX 1m 18 19 kubectl get pv #查看pv绑定 20 NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE 21 pv001 1Gi RWO,RWX Retain Available 6m 22 pv002 2Gi RWO Retain Bound default/myappdata-myapp-0 6m 23 pv003 2Gi RWO,RWX Retain Bound default/myappdata-myapp-1 6m 24 pv004 2Gi RWO,RWX Retain Bound default/myappdata-myapp-2 6m 25 pv005 2Gi RWO,RWX Retain Available 6m 26 27 kubectl get pods #查看Pod信息 28 NAME READY STATUS RESTARTS AGE 29 myapp-0 1/1 Running 0 2m 30 myapp-1 1/1 Running 0 2m 31 myapp-2 1/1 Running 0 2m 32 33 kubectl delete -f stateful-demo.yaml 34 35 //当删除的时候是从myapp-2开始进行删除的，关闭是逆向关闭 36 kubectl get pods -w 37 38 //此时PVC依旧存在的，再重新创建pod时，依旧会重新去绑定原来的pvc 39 kubectl apply -f stateful-demo.yaml 40 41 kubectl get pvc 42 NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE 43 myappdata-myapp-0 Bound pv002 2Gi RWO 5m 44 myappdata-myapp-1 Bound pv003 2Gi RWO,RWX 5m 45 myappdata-myapp-2 Bound pv004 2Gi RWO,RWX
滚动更新
1 //StatefulSet 控制器将在 StatefulSet 中删除并重新创建每个 Pod。它将以与 Pod 终止相同的顺序进行（从最大的序数到最小的序数），每次更新一个 Pod。在更新其前身之前，它将等待正在更新的 Pod 状态变成正在运行并就绪。如下操作的滚动更新是按照2-0的顺序更新。 2 vim stateful-demo.yaml #修改image版本为v2 3 ..... 4 image: ikubernetes/myapp:v2 5 .... 6 7 kubectl apply -f stateful-demo.yaml 8 9 kubectl get pods -w #查看滚动更新的过程 10 NAME READY STATUS RESTARTS AGE 11 myapp-0 1/1 Running 0 29s 12 myapp-1 1/1 Running 0 27s 13 myapp-2 0/1 Terminating 0 26s 14 myapp-2 0/1 Terminating 0 30s 15 myapp-2 0/1 Terminating 0 30s 16 myapp-2 0/1 Pending 0 0s 17 myapp-2 0/1 Pending 0 0s 18 myapp-2 0/1 ContainerCreating 0 0s 19 myapp-2 1/1 Running 0 31s 20 myapp-1 1/1 Terminating 0 62s 21 myapp-1 0/1 Terminating 0 63s 22 myapp-1 0/1 Terminating 0 66s 23 myapp-1 0/1 Terminating 0 67s 24 myapp-1 0/1 Pending 0 0s 25 myapp-1 0/1 Pending 0 0s 26 myapp-1 0/1 ContainerCreating 0 0s 27 myapp-1 1/1 Running 0 30s 28 myapp-0 1/1 Terminating 0 99s 29 myapp-0 0/1 Terminating 0 100s 30 myapp-0 0/1 Terminating 0 101s 31 myapp-0 0/1 Terminating 0 101s 32 myapp-0 0/1 Pending 0 0s 33 myapp-0 0/1 Pending 0 0s 34 myapp-0 0/1 ContainerCreating 0 0s 35 myapp-0 1/1 Running 0 1s 36 37 38 //在创建的每一个Pod中，每一个pod自己的名称都是可以被解析的 39 kubectl exec -it myapp-0 /bin/sh 40 Name: myapp-0.myapp-svc.default.svc.cluster.local 41 Address 1: 10.244.2.27 myapp-0.myapp-svc.default.svc.cluster.local 42 / # nslookup myapp-1.myapp-svc.default.svc.cluster.local 43 nslookup: can't resolve '(null)': Name does not resolve 44 45 Name: myapp-1.myapp-svc.default.svc.cluster.local 46 Address 1: 10.244.1.14 myapp-1.myapp-svc.default.svc.cluster.local 47 / # nslookup myapp-2.myapp-svc.default.svc.cluster.local 48 nslookup: can't resolve '(null)': Name does not resolve 49 50 Name: myapp-2.myapp-svc.default.svc.cluster.local 51 Address 1: 10.244.2.26 myapp-2.myapp-svc.default.svc.cluster.local 52 53 //从上面的解析，我们可以看到在容器当中可以通过对Pod的名称进行解析到ip。其解析的域名格式如下： 54 (pod_name).(service_name).(namespace_name).svc.cluster.local
部分总结
无状态：
1）deployment 认为所有的pod都是一样的
2）不用考虑顺序的要求
3）不用考虑在哪个node节点上运行
4）可以随意扩容和缩容
有状态
1）实例之间有差别，每个实例都有自己的独特性，元数据不同，例如etcd，zookeeper
2）实例之间不对等的关系，以及依靠外部存储的应用。
常规service和无头服务区别
service：一组Pod访问策略，提供cluster-IP群集之间通讯，还提供负载均衡和服务发现。
Headless service：无头服务，不需要cluster-IP，而是直接以DNS记录的方式解析出被代理Pod的IP地址。
1 vim pod6.yaml 2 apiVersion: v1 3 kind: Pod 4 metadata: 5 name: dns-test 6 spec: 7 containers: 8 - name: busybox 9 image: busybox:1.28.4 10 args: 11 - /bin/sh 12 - -c 13 - sleep 36000 14 restartPolicy: Never 15 16 17 vim sts.yaml 18 apiVersion: v1 19 kind: Service 20 metadata: 21 name: nginx 22 labels: 23 app: nginx 24 spec: 25 ports: 26 - port: 80 27 name: web 28 clusterIP: None 29 selector: 30 app: nginx 31 --- 32 apiVersion: apps/v1beta1 33 kind: StatefulSet 34 metadata: 35 name: nginx-statefulset 36 namespace: default 37 spec: 38 serviceName: nginx 39 replicas: 3 40 selector: 41 matchLabels: 42 app: nginx 43 template: 44 metadata: 45 labels: 46 app: nginx 47 spec: 48 containers: 49 - name: nginx 50 image: nginx:latest 51 ports: 52 - containerPort: 80 53 54 55 kubectl apply -f sts.yaml 56 57 kubectl apply -f pod6.yaml 58 59 kubectl get pods,svc 60 61 kubectl exec -it dns-test sh 62 / # nslookup nginx-statefulset-0.nginx.default.svc.cluster.local 63 / # nslookup nginx-statefulset-1.nginx.default.svc.cluster.local 64 / # nslookup nginx-statefulset-2.nginx.default.svc.cluster.local 65 66 kubectl exec -it nginx-statefulset-0 bash 67 /# curl nginx-statefulset-0.nginx 68 /# curl nginx-statefulset-1.nginx 69 /# curl nginx-statefulset-2.nginx
//扩展伸缩
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 #动态查看缩容
3、DaemonSet
DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
使用 DaemonSet 的一些典型用法：
●运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。
●在每个 Node 上运行日志收集 daemon，例如fluentd、logstash。
●在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。
应用场景：Agent
//官方案例（监控）
示例：
1 vim ds.yaml 2 apiVersion: apps/v1 3 kind: DaemonSet 4 metadata: 5 name: nginx-daemonSet 6 labels: 7 app: nginx 8 spec: 9 selector: 10 matchLabels: 11 app: nginx 12 template: 13 metadata: 14 labels: 15 app: nginx 16 spec: 17 containers: 18 - name: nginx 19 image: nginx:1.15.4 20 ports: 21 - containerPort: 80 22 23 24 kubectl apply -f ds.yaml 25 26 //DaemonSet会在每个node节点都创建一个Pod 27 kubectl get pods 28 nginx-deployment-4kr6h 1/1 Running 0 35s 29 nginx-deployment-8jrg5 1/1 Running 0 35s
4、Job
Job分为普通任务（Job）和定时任务（CronJob）
常用于运行那些仅需要执行一次的任务
应用场景：数据库迁移、批处理脚本、kube-bench扫描、离线数据处理，视频解码等业务
示例：
1 vim job.yaml 2 apiVersion: batch/v1 3 kind: Job 4 metadata: 5 name: pi 6 spec: 7 template: 8 spec: 9 containers: 10 - name: pi 11 image: perl 12 command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] 13 restartPolicy: Never 14 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镜像，因为镜像比较大，所以建议提前下载好
1 docker pull perl 2 3 kubectl apply -f job.yaml 4 5 kubectl get pods 6 pi-bqtf7 0/1 Completed 0 41s 7 8 //结果输出到控制台 9 kubectl logs pi-bqtf7 10 3.14159265...... 11 12 //清除job资源 13 kubectl delete -f job.yaml 14 15 //backoffLimit 16 vim job-limit.yaml 17 apiVersion: batch/v1 18 kind: Job 19 metadata: 20 name: busybox 21 spec: 22 template: 23 spec: 24 containers: 25 - name: busybox 26 image: busybox 27 imagePullPolicy: IfNotPresent 28 command: ["/bin/sh", "-c", "sleep 10;date;exit 1"] 29 restartPolicy: Never 30 backoffLimit: 2 31 32 kubectl apply -f job-limit.yaml 33 34 kubectl get job,pods 35 NAME COMPLETIONS DURATION AGE 36 job.batch/busybox 0/1 4m34s 4m34s 37 38 NAME READY STATUS RESTARTS AGE 39 pod/busybox-dhrkt 0/1 Error 0 4m34s 40 pod/busybox-kcx46 0/1 Error 0 4m 41 pod/busybox-tlk48 0/1 Error 0 4m21s 42 43 kubectl describe job busybox 44 ...... 45 Warning BackoffLimitExceeded 43s job-controller Job has reached the specified backoff limit
5、CronJob
周期性任务，像Linux的Crontab一样。
周期性任务
应用场景：通知，备份
示例：
//每分钟打印hello
1 vim cronjob.yaml 2 apiVersion: batch/v1beta1 3 kind: CronJob 4 metadata: 5 name: hello 6 spec: 7 schedule: "*/1 * * * *" 8 jobTemplate: 9 spec: 10 template: 11 spec: 12 containers: 13 - name: hello 14 image: busybox 15 imagePullPolicy: IfNotPresent 16 args: 17 - /bin/sh 18 - -c 19 - date; echo Hello from the Kubernetes cluster 20 restartPolicy: OnFailure 21 22 //cronjob其它可用参数的配置 23 spec: 24 concurrencyPolicy: Allow #要保留的失败的完成作业数（默认为1） 25 schedule: '*/1 * * * *' #作业时间表。在此示例中，作业将每分钟运行一次 26 startingDeadlineSeconds: 15 #pod必须在规定时间后的15秒内开始执行，若超过该时间未执行，则任务将不运行，且标记失败 27 successfulJobsHistoryLimit: 3 #要保留的成功完成的作业数（默认为3） 28 terminationGracePeriodSeconds: 30 #job存活时间 默认不设置为永久 29 jobTemplate: #作业模板。这类似于工作示例 30 31 32 kubectl create -f cronjob.yaml 33 34 kubectl get cronjob 35 NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE 36 hello */1 * * * * False 0 <none> 25s 37 38 kubectl get pods 39 NAME READY STATUS RESTARTS AGE 40 hello-1621587180-mffj6 0/1 Completed 0 3m 41 hello-1621587240-g68w4 0/1 Completed 0 2m 42 hello-1621587300-vmkqg 0/1 Completed 0 60s 43 44 kubectl logs hello-1621587180-mffj6 45 Fri May 21 09:03:14 UTC 2021 46 Hello from the Kubernetes cluster 47 //如果报错：Error from server (Forbidden): Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource=proxy) ( pods/log hello-1621587780-c7v54) 48 //解决办法：绑定一个cluster-admin的权限 49 kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous
总结
Pod控制器
Deployment
部署无状态应用的 管理RelicaSet（RS）和Pod创建，维护Pod副本数目与期望状态相同创建和删除Pod时候是并行执行的，升级时是先创建一部分再删除一部分
statefulSet
部署有状态的应用
每个pod唯一且不变，且每个pod拥有自己专属的持久化存储(基于PVC和PV)
在k8s集群内部可以通过，还可以通过(pod_name).(service_name).(namespace_name).svc.cluster.local解析出Pod的IP(基于headless service和CoreDNS)
创建和删除pod是有顺序的(串行执行)
升级时也是串行执行的，会先删除旧的pod，再创建新的pod
删除和升级是逆序执行的(先从标识符序号最大的[n-1]开始，一直到最小[0])
创建时是升序执行的(标识符从0到n-1)
DaemonSet
理论上可以在k8s集群的所有node节点上创建相同的Pod(不论node节点什么时候加入到k8s集群)，但是会受到node节点上污点影响
Jod
部署一次任务的pod，正常完成后容器立即退出并不会重启容器(restartPolicy 不设置always)，也不会重建pod异常完成后会重建pod重试任务，重建次数根据backoffLimit来配置指定(默认为6次)
Crontab
周期性的部署任务pod，正常完成后容器立即退出并不会重启容器(restartPolicy不设置always)，也不会重建pod schedule 配置周期性的时间表
