关于kubernetes:K8S学习笔记03-ControllerServiceDaemonJobCronJobRCRS

1次阅读

共计 5376 个字符，预计需要花费 14 分钟才能阅读完成。

Controller 是在集群上治理和运行容器的对象

Pod 是通过 Controller 实现利用的运维，比方弹性伸缩，滚动降级等

Pod 和 Controller 之间是通过 label 标签来建设关系，同时 Controller 又被称为控制器工作负载

部署无状态利用
治理 Pod 和 ReplicaSet
部署，滚动降级等
利用场景：web 服务，微服务

Deployment 示意用户对 K8S 集群的一次更新操作。Deployment 是一个比 RS(Replica Set, RS) 利用模型更广的 API 对象，能够是创立一个新的服务，更新一个新的服务，也能够是滚动降级一个服务。滚动降级一个服务，理论是创立一个新的 RS，而后逐步将新 RS 中正本数减少到现实状态，将旧 RS 中的正本数缩小到 0 的复合操作。

这样一个复合操作用一个 RS 是不好形容的，所以用一个更通用的 Deployment 来形容。以 K8S 的倒退方向，将来对所有长期伺服型的业务的治理，都会通过 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         109MB

2. 降级 nginx1.15

kubectl set image deployment web nginx=nginx:1.15

3. 查看降级状态

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 负责定义一组 Pod 的拜访规定
Service 是客户端须要拜访的服务对象。每个 Service 会对应一个集群外部无效的虚构 IP，集群外部通过虚构 IP 拜访一个服务。

避免 Pod 失联【服务发现】
定义 Pod 拜访策略【负载平衡】

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

页背后端的 Pod 拜访到后端的 Pod，两头会通过 Service 一层，而 Service 在这里还能做负载平衡：

随机
轮询
响应比

Pod 和 Service 之间还是依据 label 和 selector 建设关联的。

ClusterIp：集群外部拜访
NodePort：对外拜访利用应用
LoadBalancer：对外拜访利用应用，私有云

无状态

每个 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 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          2m42s

kubectl 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

后盾撑持型服务的外围关注点在 K8S 集群中的节点(物理机或虚拟机)，要保障每个节点上都有一个此类 Pod 运行。节点可能是所有集群节点，也可能是通过 nodeSelector 选定的一些特定节点。典型的后盾撑持型服务包含：存储、日志和监控等。在每个节点上撑持 K8S 集群运行的服务。

守护过程: 在每个节点上运行同一个 pod，新退出的节点也同样运行同一个 pod

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

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

进入某个 Pod 外面，进入

kubectl exec -it ds-test-cbk6v bash

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

一次性工作：一次性执行完就完结
定时工作：周期性执行

Job 是 K8S 中用来管制批处理型工作的 API 对象。批处理业务与长期伺服业务的次要区别就是批处理业务的运行有头有尾，而长期伺服业务在用户不进行的状况下永远运行。Job 治理的 Pod 依据用户的设置把工作胜利实现就主动退出了。胜利实现的标记依据不同的 spec.completions 策略而不同：单 Pod 型工作有一个 Pod 胜利就标记实现；定数胜利行工作保障有 N 个工作全副胜利；工作队列性工作依据利用确定的全局胜利而标记胜利。

查看目前曾经存在的 Job

kubectl get jobs

在计算实现后，通过命令查看，可能发现该工作曾经实现

咱们能够通过查看日志，查看到一次性工作的后果

kubectl logs pi-qpqff

创立定时工作

kubectl apply -f cronjob.yaml

查看日志

kubectl logs hello-1599100140-wkn79

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

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 简称 RS，也就是正本集。RS 是新一代的 RC，提供同样高可用能力，区别次要在于 RS 青出于蓝，可能反对更多品种的匹配模式。正本集对象个别不独自应用，而是作为 Deployment 的现实状态参数来应用

.
.
.
.
.
.

正文完

kubernetes

发表至： kubernetes

2021-08-15

0

关于kubernetes:kubernetesk8s命名空间一直Terminating

关于kubernetes:Kubernetesk8s最大启动时长研究

关于kubernetes:Kubernetes-v127-新特性一览

关于kubernetes:基于-KubeVela-的-GitOps-交付

关于vim:oeasy教您玩转vim-17-向上向下

关于kubernetes:K8S学习笔记03-ControllerServiceDaemonJobCronJobRCRS

Controller

什么是 Controller

Pod 和 Controller 的关系

Deployment 控制器利用

Deployment 利用场景

Deployment 部署无状态利用

利用降级回滚

弹性伸缩

Service

Service 的存在意义

避免 Pod 失联

定义 Pod 拜访策略

Pod 和 Service 的的关系

Service 罕用类型

Statefulset 有状态利用

无状态和有状态

无状态

有状态

部署有状态利用

DaemonSet 后盾撑持型服务，次要是用来部署守护过程

Job 和 CronJob 一次性工作和定时工作

Job 一次性工作

CronJob 定时工作

Replication Controller

Replica Set

站内搜索

关于kubernetes:K8S学习笔记03-ControllerServiceDaemonJobCronJobRCRS

Controller

什么是 Controller

Pod 和 Controller 的关系

Deployment 控制器利用

Deployment 利用场景

Deployment 部署无状态利用

利用降级回滚

弹性伸缩

Service

Service 的存在意义

避免 Pod 失联

定义 Pod 拜访策略

Pod 和 Service 的的关系

Service 罕用类型

Statefulset 有状态利用

无状态和有状态

无状态

有状态

部署有状态利用

DaemonSet 后盾撑持型服务，次要是用来部署守护过程

Job 和 CronJob 一次性工作 和 定时工作

Job 一次性工作

CronJob 定时工作

Replication Controller

Replica Set

站内搜索

Job 和 CronJob 一次性工作和定时工作