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之间建设关系的桥梁
部署利用
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.yaml
kubectl get pods,svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/web1 NodePort 10.102.100.115 <none> 80:30222/TCP 59s测试拜访
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 wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
web-66bf4959f5-lgxmr 1/1 Running 0 83s 10.244.2.10 k8s-node2 <none> <none>
#到指定节点（k8s-node2）查看镜像版本
docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx 1.14 295c7be07902 2 years ago 109MB2.降级nginx1.15
kubectl set image deployment web nginx=nginx:1.153.查看降级状态
kubectl rollout status deployment web
deployment "web" successfully rolled out查看历史版本
kubectl rollout history deployment web
deployment.apps/web
REVISION CHANGE-CAUSE
1 <none>
2 <none>4.利用回滚
#上一个版本
kubectl rollout undo deployment web
#指定版本
kubectl rollout undo deployment web --to-revision=2弹性伸缩
kubectl scale deployment web --replicas=10查看Pod列表
kubectl get pods
NAME READY STATUS RESTARTS AGE
web-bbcf684cb-2mjcb 1/1 Running 0 8s
web-bbcf684cb-9rc6h 0/1 ContainerCreating 0 8s
web-bbcf684cb-dhsdj 0/1 ContainerCreating 0 8s
web-bbcf684cb-ht9nd 0/1 ContainerCreating 0 8s
web-bbcf684cb-nqzcl 1/1 Running 0 7m17s
web-bbcf684cb-qhr9k 0/1 ContainerCreating 0 8s
web-bbcf684cb-slc7d 0/1 ContainerCreating 0 8s
web-bbcf684cb-tmrw9 0/1 ContainerCreating 0 8s
web-bbcf684cb-vt7xv 0/1 ContainerCreating 0 8s
web-bbcf684cb-x6qgr 0/1 ContainerCreating 0 8s 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: 80kubectl apply -f sts.yaml - 查看部署状态
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-statefulset-0 1/1 Running 0 2m45s
nginx-statefulset-1 1/1 Running 0 2m43s
nginx-statefulset-2 1/1 Running 0 2m42skubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 40h
nginx ClusterIP None <none> 80/TCP 3m7s
web1 NodePort 10.102.100.115 <none> 80:30222/TCP 10h删除
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 services
kubectl 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的现实状态参数来应用
.
.
.
.
.
.
发表回复