K8S学习笔记03 Controller,Service,Daemon,Job,CronJob,RC,RS kubernetes

Controller 什么是Controller
Controller是在集群上管理和运行容器的对象
Pod和Controller的关系
Pod是通过Controller实现应用的运维，比如弹性伸缩，滚动升级等
Pod 和 Controller之间是通过label标签来建立关系，同时Controller又被称为控制器工作负载

文章图片

Deployment控制器应用
Deployment应用场景

部署无状态应用
管理Pod和ReplicaSet
部署，滚动升级等
应用场景：web服务，微服务

Deployment表示用户对K8S集群的一次更新操作。Deployment是一个比RS( Replica Set, RS) 应用模型更广的 API 对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新 RS 中副本数增加到理想状态，将旧RS中的副本数减少到0的复合操作。
这样一个复合操作用一个RS是不好描述的，所以用一个更通用的Deployment来描述。以K8S的发展方向，未来对所有长期伺服型的业务的管理，都会通过Deployment来管理。
Deployment部署无状态应用

kubectl create deployment web --image=nginx --dry-run -o yaml > web.yaml

我们看到的 selector 和 label 就是我们Pod 和 Controller之间建立关系的桥梁

K8S学习笔记03 Controller,Service,Daemon,Job,CronJob,RC,RS

文章图片

部署应用

kubectl apply -f web.yaml

对外暴露端口

kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1 -o yaml > web1.yaml--port：内部的端口号，用于集群内部访问 --target-port：容器向外暴露的端口号 --name：名称 --type：类型

重新部署

kubectl apply -f web.yamlkubectl get pods,svcNAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)AGE service/web1NodePort10.102.100.11580:30222/TCP59s

测试访问

curl http://119.45.29.8:30222/

应用升级回滚 1.先安装nginx1.14版本

vim web.yaml#指定nginx1.14 - image: nginx:1.14#重新部署 kubectl apply -f web.yaml#查看部署状态 kubectl get pods -o wideNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATED NODEREADINESS GATES web-66bf4959f5-lgxmr1/1Running083s10.244.2.10k8s-node2#到指定节点（k8s-node2）查看镜像版本 docker imagesREPOSITORYTAGIMAGE IDCREATEDSIZE nginx1.14295c7be079022 years ago109MB

2.升级nginx1.15

kubectl set image deployment web nginx=nginx:1.15

3.查看升级状态

kubectl rollout status deployment webdeployment "web" successfully rolled out

查看历史版本

kubectl rollout history deployment webdeployment.apps/web REVISIONCHANGE-CAUSE 1 2

4.应用回滚

#上一个版本 kubectl rollout undo deployment web#指定版本 kubectl rollout undo deployment web --to-revision=2

弹性伸缩

kubectl scale deployment web --replicas=10

查看Pod列表

kubectl get pods NAMEREADYSTATUSRESTARTSAGE web-bbcf684cb-2mjcb1/1Running08s web-bbcf684cb-9rc6h0/1ContainerCreating08s web-bbcf684cb-dhsdj0/1ContainerCreating08s web-bbcf684cb-ht9nd0/1ContainerCreating08s web-bbcf684cb-nqzcl1/1Running07m17s web-bbcf684cb-qhr9k0/1ContainerCreating08s web-bbcf684cb-slc7d0/1ContainerCreating08s web-bbcf684cb-tmrw90/1ContainerCreating08s web-bbcf684cb-vt7xv0/1ContainerCreating08s web-bbcf684cb-x6qgr0/1ContainerCreating08s

Service

Service 负责定义一组Pod的访问规则
Service 是客户端需要访问的服务对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。

Service的存在意义

防止Pod失联【服务发现】
定义Pod访问策略【负载均衡】

防止Pod失联

Pod每次创建都对应一个短暂的IP地址，每次Pod更新都会变化，
前端页面有多个Pod时，同时后端也多个Pod，相互访问需要通过Service拿到Pod的IP地址，然后去访问对应的Pod

文章图片

定义Pod访问策略页面前端的Pod访问到后端的Pod，中间会通过Service一层，而Service在这里还能做负载均衡：

随机
轮询
响应比

Pod和Service的的关系
Pod 和 Service 之间还是根据 label 和 selector 建立关联的。

文章图片

Service常用类型

ClusterIp：集群内部访问
NodePort：对外访问应用使用
LoadBalancer：对外访问应用使用，公有云

Statefulset 有状态应用
无状态和有状态无状态

每个Pod副本都是一样的
没有顺序要求
不考虑应用在哪个node上运行
能够进行随意伸缩和扩展

有状态

让每个Pod独立的
让每个Pod独立的，保持Pod启动顺序和唯一性
唯一的网络标识符，持久存储
有序，比如mysql中的主从

适合StatefulSet的业务包括数据库服务MySQL 和 PostgreSQL，集群化管理服务Zookeeper、etcd等有状态服务
StatefulSet的另一种典型应用场景是作为一种比普通容器更稳定可靠的模拟虚拟机的机制。传统的虚拟机正是一种有状态的宠物，运维人员需要不断地维护它，容器刚开始流行时，我们用容器来模拟虚拟机使用，所有状态都保存在容器里，而这已被证明是非常不安全、不可靠的。
使用StatefulSet，Pod仍然可以通过漂移到不同节点提供高可用，而存储也可以通过外挂的存储来提供高可靠性，StatefulSet做的只是将确定的Pod与确定的存储关联起来保证状态的连续性。
部署有状态应用

无头service => ClusterIp：none

文章图片

创建无头service
部署有状态应用

apiVersion: v1 kind: Service metadata: name: nginx labels: apps: nginx spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx---apiVersion: apps/v1 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:1.15 ports: - containerPort: 80

kubectl apply -f sts.yaml

查看部署状态

kubectl get podsNAMEREADYSTATUSRESTARTSAGE nginx-statefulset-01/1Running02m45s nginx-statefulset-11/1Running02m43s nginx-statefulset-21/1Running02m42s

kubectl get servicesNAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)AGE kubernetesClusterIP10.96.0.1443/TCP40h nginxClusterIPNone80/TCP3m7s web1NodePort10.102.100.11580:30222/TCP10h

删除

kubectl delete statefuset --all

问题：

The Service "nginx" is invalid: * spec.clusterIP: Invalid value: "None": field is immutable * spec.clusterIP: Invalid value: "None": may not be set to 'None' for NodePort services

解决：删掉已有nginx service

kubectl get serviceskubectl delete service nginx

这里有状态的约定，肯定不是简简单单通过名称来进行约定，而是更加复杂的操作

deployment：是有身份的，有唯一标识
statefulset：根据主机名 + 按照一定规则生成域名
每个pod有唯一的主机名，并且有唯一的域名

格式：主机名称.service名称.名称空间.svc.cluster.local
举例：nginx-statefulset-0.default.svc.cluster.local
DaemonSet 后台支撑型服务，主要是用来部署守护进程后台支撑型服务的核心关注点在K8S集群中的节点(物理机或虚拟机)，要保证每个节点上都有一个此类Pod运行。节点可能是所有集群节点，也可能是通过 nodeSelector选定的一些特定节点。典型的后台支撑型服务包括：存储、日志和监控等。在每个节点上支撑K8S集群运行的服务。

守护进程: 在每个节点上运行同一个pod，新加入的节点也同样运行同一个pod

例子：在每个node节点安装数据采集工具

文章图片

这里是不是一个FileBeat镜像，主要是为了做日志采集工作

文章图片

进入某个 Pod里面，进入

kubectl exec -it ds-test-cbk6v bash

通过该命令后，我们就能看到我们内部收集的日志信息了

文章图片

Job和CronJob 一次性任务和定时任务

一次性任务：一次性执行完就结束
定时任务：周期性执行

Job是K8S中用来控制批处理型任务的API对象。批处理业务与长期伺服业务的主要区别就是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的 spec.completions 策略而不同：单Pod型任务有一个Pod成功就标志完成；定数成功行任务保证有N个任务全部成功；工作队列性任务根据应用确定的全局成功而标志成功。
Job 一次性任务

文章图片

查看目前已经存在的Job

kubectl get jobs

文章图片

在计算完成后，通过命令查看，能够发现该任务已经完成

文章图片

我们可以通过查看日志，查看到一次性任务的结果

kubectl logs pi-qpqff

文章图片

CronJob 定时任务

文章图片

创建定时任务

kubectl apply -f cronjob.yaml

文章图片

查看日志

kubectl logs hello-1599100140-wkn79

文章图片

每次执行，就会多出一个Completed的pod

文章图片

Replication Controller Replication Controller 简称 RC，是K8S中的复制控制器。RC是K8S集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就会启动新的Pod副本；多于指定数目，RC就会杀死多余的Pod副本。
即使在指定数目为1的情况下，通过RC运行Pod也比直接运行Pod更明智，因为RC也可以发挥它高可用的能力，保证永远有一个Pod在运行。RC是K8S中较早期的技术概念，只适用于长期伺服型的业务类型，比如控制Pod提供高可用的Web服务。
Replica Set Replica Set 简称 RS，也就是副本集。RS是新一代的RC，提供同样高可用能力，区别主要在于RS后来居上，能够支持更多种类的匹配模式。副本集对象一般不单独使用，而是作为Deployment的理想状态参数来使用
【K8S学习笔记03 Controller,Service,Daemon,Job,CronJob,RC,RS】.
.
.
.
.
.