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 的现实状态参数来应用
.
.
.
.
.
.