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的理想状态参数来使用
.
.
.
.
.
.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。