kubernetes-pod控制器-4
pod控制器controller对于k8s系统的来说API Server是整个集群入口的gateway，并且它还是一个Restfull系统, 做为一个Restfull风格的系统, 其所管理的内容通通会被抽象成resources， pod控制器就是一个resources, 并且我们创建出的每一个pod都是一个具体的Object；API Server为整个Kubernetes的数据管理提供了一种数
pod控制器
controller
对于k8s系统的来说API Server是整个集群入口的gateway，并且它还是一个Restfull系统, 做为一个Restfull风格的系统, 其所管理的内容通通会被抽象成resources， pod控制器就是一个resources, 并且我们创建出的每一个pod都是一个具体的Object；
API Server为整个Kubernetes的数据管理提供了一种数据范式，所有存取于API Server的数据，都必须遵循于Resources这样的一个规范，比如我们需要创建一个Pod时候，应该在Pod上调用哪个属性，给哪个值，所有的数据都保存在etcd当中;
保存在etcd中的数据将会被构建为k8s的活动对象，而活动对象状态成为什么的结构，则取决于各种各种样的 controller， controller负责创建修改各种 活动对象， 当活动对象创建时它的基本标准是由存储于etcd用户定义的存储对象， 所以在etcd当中，我们称为用户期望的对象 ;
controller 从中取出来用户所期望的标准， 负责将它创建在当前的k8s集群上成为活动对象， 并且Controller 还会负责通过和解Reconcilation Loops，确保在每一个时刻Live Objects要与用户所定义的Objects要保持一致， status状态需要与spec中状态保持一致， status由controller负责维护， 而spec则由用户负责维护
k8s通过将控制器代码打成成一个统一的守护进程， kube-controller-manage管理k8s集群中各式各样的控制器的和解循环(control loop)的实现, 后续所有的controller都会在它的维护中来确保控制器的正常运行；
比如k8s控制器用于控制Pod, Pod出现故障时由Pod控制器来进行销毁重建， Pod控制器内部也有和解循环， 而我们 controller-manage可以高可用， 如果用户不需要这个Pod控制器的话，那么也会自动将Pod控制器下面的Pod对象删除；
- yaml创建的就是自主式pod，而自主式pod不是由控制器控制和管理的资源
- pod控制器用于实现代为管理Pod的中间层，并确保pod资源始终处于自行定义所期望的资源状态(status)
- 当pod出现故障，pod控制器会尝试着重启容器，如果重启一直失败那么它将会重新编排，如果pod低于用户所定义的资源状态，那么控制器将会删除或增加资源
kube-controller-manager
黄色的控制器是Pod控制器，其他的是其他资源的控制器，这些才是Kubernetes背后的资源管理大脑，所以整个Kubernetes的各种高级功能都是借助于Contrller完成的，对于Contrller来讲，它们才是真正的确保任务编排系统之所以成为编排系统的核心组件，因为编排任务当中的比如像自动创建、自动恢复等等高级功能，基本都是依赖于Contrller完成的，所以从某种意义上来讲，Contrller如果复杂一点的话，我们甚至可以把它称为运维器或者操作器；
那么对于kube-controller-manager来讲，它是整个Kubernetes控制平面一个非常重要的守护进程，其实Kubernetes每一个守护进程都可以通过配置选项来配置，只不过我们在此之前将其运行成为了一个Pod，如果我们期望自定义的kube-controller-manager的类型被启用，可以在启动这个进程时通过 --controllers来指定要启用的控制器，默认是*;
使用kubeadm安装kube-controller-manager的时候，默认配置文件地址：/etc/kubernetes/manifests/kube-controller-manager.yaml 修改完成之后不需要重启，会自动重建；
当我们在定义Pod时，不应该手动去创建, 因为Pod控制器是建立在基础资源之上的进一步抽象， k8s之所以能够自动编排， 是完全依赖于控制器来实现的, 因为我们应该创建控制器对象来管理这些基础资源类型， Pod控制器是只是一种统称，早期的Kubernetes版本只有一种控制器，ReplicationController，现在这一个控制器被划分为多种类型，第一种叫守护进程型，守护进程型，又可以分为有状态应用，和无状态应用，第二种非守护进程型，例如备份任务；
控制器分类
守护进程型：
无状态：
非系统级：Deployment ReplicaSet
系统级：DaemonSet
有状态：
SataefulSet
非守护进程型：
Job
CronJob
一、ReplicaSet
主要用来控制非系统级的无状态守护进程的应用, 代用户创建指定数据的pod副本，并确保Pod副本一直满足用户所期望的数量状态，资源将遵行多退少补概念，并支持扩缩机制， ReplicationController已被废弃，推荐使用：ReplicaSet， 主要由三个组件组成， k8s不建议直接使用ReplicaSet，推荐使用 Deployment
1.1、组件说明
| 组件功能 | 说明 |
|---|---|
| pod副本 | 用户期望的pod副本数量， 管控副本有多少个 |
| 标签选择器 | 选定由自己管理和控制的pod副本， 以此判定哪些pod由自己管理 |
| pod资源模板 | 当控制器中的pod数量少于定义的pod数量，那么就会根据模板来完成pod 资源的新建， |
1.2、参数说明
- 查看状态
~]# kubectl explain rs # 简写 replicaSet
KIND: ReplicaSet
VERSION: apps/v1
- 副本数量
replicase: # 创建几个副本数量 replicas <integer>
- 标签选择器
selector： # 标签选择器 selector <Object> -required-
matchExpressions <[]Object> # 匹配表达式,这个标签可以指定一段
matchLabels <map[string]string> # 等值标签选择， 语法为键值对
- 副本模板
template： # 副本模板 template <Object>
metadata: # pod资源本身的元数据，由selector控制的元数据
labels: # 必须符合selector的标签器中的标准，否则创建将会永无休止， 也可以是其它的标签
spec: # 模板的资源
- spec: pod资源本身的资源
1.3、demo
1.3.1、创建yaml
apiVersion: apps/v1 # 正式版本
kind: ReplicaSet # pod控制器
metadata: # 元数据类型
name: first-rs-app # 新创建pod的名称
labels:
app: first-app # 这里定义的是 rs的标签
release: firsts
spec:
replicas: 4 # 定义副本数据为4个
selector: # 标签选择器，定义匹配的pod标签
matchLabels: # pod只要符合下面两个标签就会归该选择器
app: first-app
release: firsts
template: # pod的模板
metadata: # pod源数据
name: apps # pod名称， 在describe中也不会显示
namespace: default # 名称空间
labels: # pod的标签， 需要与 matchLables一致，否则该yaml就无法控制pod
app: first-app
release: firsts
envs: apps # 也可以多出其它的
spec:
containers: # pod的资源
- name: my-container # 名称
image: ikubernetes/myapp:v1 # pod容器镜像
imagePullPolicy: IfNotPresent # 如果没有就下载
ports: # 定义expose的端口
- name: http
containerPort: 80
readinessProbe: # 存活性探测
initialDelaySeconds: 3 # 初始化3秒之后开始
failureThreshold: 3 # 失败三次就认为失败
httpGet: # 检测80端口以及访问index.html页面
port: http
path: index.html
1.3.2、查看pod资源
# 创建pod
]# kubectl create -f first_replicaset.yaml
# 查看rs详细信息
]# kubectl get rs -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
first-rs-app 4 4 4 11m my-container ikubernetes/myapp:v1 app=first-app,release=firsts
# 查看更详细的rs状态
]# kubectl describe rs
Name: first-rs-app
Namespace: default
Selector: app=first-app,release=firsts
Labels: app=first-app
release=firsts
Annotations: <none>
Replicas: 4 current / 4 desired
Pods Status: 4 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=first-app
envs=apps
release=firsts
Containers:
my-container:
Image: ikubernetes/myapp:v1
Port: 80/TCP
Host Port: 0/TCP
Readiness: http-get http://:http/index.html delay=3s timeout=1s period=10s #success=1 #failure=3
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 12m replicaset-controller Created pod: first-rs-app-q7bnc
Normal SuccessfulCreate 12m replicaset-controller Created pod: first-rs-app-xrtdw
Normal SuccessfulCreate 12m replicaset-controller Created pod: first-rs-app-jrkhh
Normal SuccessfulCreate 12m replicaset-controller Created pod: first-rs-app-xzksd
Normal SuccessfulCreate 11m replicaset-controller Created pod: first-rs-app-n55kh
1.3.3、操作pod
# 随便删除一个pod， 它会自动生成pod
]# kubectl delete pod first-rs-app-xrtdw
pod "first-rs-app-xrtdw" deleted
# 编辑 rs
]# kubectl edit rs first-rs-app
# 修改replicase可以立即生效
# 修改 spec.containers.image不会立即生效，需要手动一个个操作
# 删除rs
]# kubectl delete rs first-rs-app
replicaset.apps "first-rs-app" deleted
使用控制器创建一组不分彼此的pod资源时，控制器创建的pod要想能够被客户端不受生命周期所影响，用户就需要有一个固定的访问端点，而访问端点需要在pod外在加一个server选择器，server需要与pod是同一个标签，以便关连pod资源，而后用户通过server访问，server会直接代理pod资源， server与Pod并不需要与控制器有一一对应关系
二、Deployment
当使用ReplicaSet时，创建的Pod并不会因为在配置文件中修改版本应用而生效，所以在rs下要想真正更新Pod， 每次删一个Pod等它重建完成，再删第二个，依次类推完成灰度发布 (滚动发布)， 但是因为Pod的会实时收到监控，一旦数量少于预定义的数量就会创建，因此就需要使用先加后减的策略进行，先加后减是确保当前的可用节点数量，但是如果这样的话，就比较繁琐；
那么我们的Kubernetes就专门提供了一个控制器来负责，完成此类功能，它被称为Deployment，也就意味着在Kubernetes之上我们不应该人为去手动使用ReplicaSet存在的目的，只是用来管理底层Pod的，但我们用户来管理的是Deployment，Deployment负责由Controller来管理RS，RS负责管理Pod，它能利用RS功能帮用户完成各种操作，比如版本升级，回滚，灰度发布，金丝雀发布等
- 灰度 ： 删一个加一个， 真正做到了滚动发布
- 金丝雀: 当使用deployment发布时，使用先加后减的方式, 但对于金丝雀发布只加不减，新老版本并存，暂停了,我们可以使用路由策略把一部分用户量不大的区域的流量放到新的Pod里面，而用户量比较大的地区还是使用老版本的Pod，而这一切在Deployment上，都可用自动进行，你只需要告诉它更新一批并且暂停下来，那就是金丝雀
如果需要实现流量调度，Kubernetes目前默认提供的组件还没这个能力，需要借助其他的网络组件实现， deployment支持回滚操作,deploymnet实现方式是将历史Pod进行保留不删除，在其必要的时候还能够基于历史的Pod进行回滚， 默认保存十个版本， 而现在应该是保留所有版本；
而且对于回滚来说，它还是基于灰度发布， 删完重建依次循环，假设有6个Pod那么依次删除并建立消耗的时间会很长，但对于deployment来说它可以在原有的基础上先增加一个或多个然后在删除原有老版的， 或者先删除多个然后在创建， 所以说RS不应该是我们直接使用，rs存在的目的只是为了管理底层的Pod；
对于我们用户应该使用的是Deployment，Deployment负责由控制器来管理ReplicaSet，ReplicaSet来管理Pod，所以Deployment是一个更高级的功能，它能利用ReplicaSet的功能帮我们完成各种更新策略；
-
工作在ReplicaSet之上，Deployment控制ReplicaSet来控制pod，用于管理无状态应用，目前来说最好的控制器。
-
拥有ReplicaSet所有的功能，支持滚动更新和回滚功能，也提供声明式配置。
-
一个节点可以运行多个Deployment副本，也可以一个不运行， pod数量可以大于节点数
2.1、更新方式
- 更新方式一： 允许节点多创建一个
- 更新方式二： 允许节点少一个
升级步骤 从v1逐步升级至v2, v1最后全部迁移之后, v1的控制器也不会被删除, 用于版本回退，更新时默认是灰度\滚动的方式进行，根据粒度滚动更新(一次新增几个或一次允许少几个)， 在更新时livenessProbe或readnessProbe时最为重要。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nZJ2MjaD-1591840603154)(C:\Users\xiong\AppData\Roaming\Typora\typora-user-images\dev\1576217581894.png)]
deployment 建立在replicaSet之上， 可管理多个rs控制器，但其中只有一个处于活跃状态，默认只会保存10个rs
2.2、参数说明
-
查看状态
~]# kubectl explain deploy KIND: Deployment VERSION: apps/v1 -
副本数量
replicase: # 创建几个副本数量 replicas <integer> -
**strategy: ** 更新策略
属性 说明 Recreate 重建更新,删除一个更新一个 RollingUpdate 滚动更新， 允许临时多几个或少几个， 创建更新的粒度 RollingUpdate属性 说明 maxSurge 对应的更新过程当中，最多能超出的目标副本数有多少个，
两个指定方式： %(百分比)跟 数字maxUnavaiable 最多有几个不可用， -
标签选择器
selector： # 标签选择器 selector <Object> -required- matchExpressions <[]Object> # 匹配表达式,这个标签可以指定一段 matchLabels <map[string]string> # 等值标签选择， 语法为键值对 -
副本模板
template： # 副本模板 template <Object> metadata: # pod资源本身的元数据，由selector控制的元数据 labels: # 必须符合selector的标签器中的标准，否则创建将会永无休止， 也可以是其它的标签 spec: # 模板的资源 -
spec: pod资源本身的资源
2.3、demo
2.3.1、创建yaml
]# cat deployment.yaml
apiVersion: apps/v1 # 版本为 正式版本
kind: Deployment # pod控制器类型
metadata: # 控制器的元数据
name: my-deploy # 控制器名称
labels: # 控制器labels
app: dly
spec:
replicas: 2 # pod副本数 三要素-1
selector:
matchLabels: # 标签选择器 三要素-2
app: my-deploy
release: base1
strategy: # 更新策略
rollingUpdate: # 滚动更新
maxSurge: 2 # 临时可以多创建2个
maxUnavailable: 1 # 可以少一个， 假设有五个1个不可用，多创建二个 最多4-7个可用
template: # pod模板 三要素-3， 每一个模板都是一个标准的对象
metadata: # pod元数据
name: my-app # pod名称
namespace: default
labels: # pod标签， 必须要与matchLabels保存一致可以多,少了就不归该控制器了
app: my-deploy
release: base1
spec: # pod属性
containers: # pod容器属性
- name: my-app # 名称
image: ikubernetes/myapp:v1 # 容器镜像
imagePullPolicy: IfNotPresent # 如果不存在就下载
ports: # 暴露端口
- name: http
containerPort: 80
readinessProbe: # 存活性探测
failureThreshold: 3 # 可接受3次失败，3次之后就直接error
initialDelaySeconds: 3 # 初始化3秒之后开始探测
httpGet: # 探测类型为http
port: http
path: index.html
spec.paused: 暂停
spec.revisionHistoryLimit: 保存多少个回滚的版本, 默认为10个
spec.strategy 更新策略
Recreate: 重建更新，删除一个建立一个，在创建出新的Pod之前会先杀掉所有已存在的Pod
RollingUpdate: 滚动更新， 允许临时多几个或少几个
maxSurge: 对应的更新过程当中，最多能超出的目标副本数有多少个， 两个指定方式： %跟数字
maxUnavaiable： 最多有几个不可用，
2.3.2、查看资源
# 查看deployment属性
]# kubectl get deploy -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
my-deploy 2/2 2 2 21s my-app ikubernetes/myapp:v1 app=my-deploy,release=base1
# 查看 replicaSet
]# kubectl get rs -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
my-deploy-8574fcbdfd 2 2 2 20m my-app ikubernetes/myapp:v1 app=my-deploy,pod-template-hash=8574fcbdfd,release=base1
# 属性说明： deployment名称-固定的hash码 my-deploy-8574fcbdfd
# 查看pod
]# kubectl get pods -l app=my-deploy
NAME READY STATUS RESTARTS AGE
# depl名称-固定hash码-随机串
my-deploy-8574fcbdfd-2c9tn 1/1 Running 0 22m
my-deploy-8574fcbdfd-qzfcm 1/1 Running 0 22m
# 查看deployment详细信息
# 换了个yaml， 查看最小跟最大， 如果不指定就是25% 不足1的会补齐1
]# kubectl describe deployments.apps my-deploy
Name: my-deploy
Namespace: default
CreationTimestamp: Mon, 16 Dec 2019 09:35:38 +0800
Labels: type=deployment
Annotations: deployment.kubernetes.io/revision: 1
kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"type":"deployment"},"name":"my-deploy","namespace":"de...
Selector: app=my-deploy,revese=deploy-v1.1
Replicas: 4 desired | 4 updated | 4 total | 4 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 2 max surge
Pod Template: # pod模板 labels
Labels: app=my-deploy
revese=deploy-v1.1
Containers:
my-container:
Image: ikubernetes/myapp:v1
Port: 80/TCP
Host Port: 0/TCP
Liveness: http-get http://:http/index.html delay=0s timeout=1s period=10s #success=1 #failure=3
查看详细版本
]# kubectl rollout history deployment my-deploy --revision=1
# --record=true # 使用--record可以在查看历史的时候查看此次记录
deployment.apps/my-deploy with revision #1
Pod Template:
Labels: app=my-deploy
pod-template-hash=5fbb68fb8c
revese=deploy-v1.1
Containers:
my-container:
Image: ikubernetes/myapp:v1
Port: 80/TCP
Host Port: 0/TCP
Liveness: http-get http://:http/index.html delay=0s timeout=1s period=10s #success=1 #failure=3
Environment: <none>
Mounts: <none>
Volumes: <none>
2.3.3、操作资源
# 修改 deployment.yaml
spec:
replicas: 4 # 副本修改为 4
template:
spec:
containers:
- name: my-app
image: ikubernetes/myapp:v2 # 版本升级
]# kubectl get deploy -o wide # 查看deploy
]# kubectl get rs -o wide # 查看rs
# 查看升级的版本
]# kubectl rollout history deployment
deployment.apps/my-deploy
REVISION CHANGE-CAUSE # 如果不加 --record在版本中就看不到具体的操作过程
1 <none>
2 <none>
修改deployment
# patch, 从v1版本 升级v2版本
~]# kubectl patch deployments my-deploy -p '{"spec": {"template":{"spec":{"containers":[{"name":"my-container","image":"ikubernetes/myapp:v2"}]}}}}'
deployment.apps/my-deploy patched
# 此时在查看history版本，就有两个了
~]# kubectl rollout history deployment
deployment.apps/my-deploy
REVISION CHANGE-CAUSE
1 <none>
2 <none>
# 查看deployment详细信息
]# kubectl describe deployments.apps my-deploy
Name: my-deploy
Namespace: default
CreationTimestamp: Mon, 16 Dec 2019 09:35:38 +0800
Labels: type=deployment
Annotations: deployment.kubernetes.io/revision: 2
kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"type":"deployment"},"name":"my-deploy","namespace":"de...
Selector: app=my-deploy,revese=deploy-v1.1
Replicas: 4 desired | 4 updated | 4 total | 4 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 2 max surge
Pod Template:
Labels: app=my-deploy
revese=deploy-v1.1
Containers:
my-container:
Image: ikubernetes/myapp:v2 # 升级版本
Port: 80/TCP
Host Port: 0/TCP
# 存活性检测
Liveness: http-get http://:http/index.html delay=0s timeout=1s period=10s #success=1 #failure=3
# 查看pods 详细信息
]# kubectl describe pods my-deploy-7ff6f44678-tvl74
Name: my-deploy-7ff6f44678-tvl74
Namespace: default
Priority: 0
Node: node1/192.168.9.31
Start Time: Mon, 16 Dec 2019 11:27:40 +0800
Labels: app=my-deploy
pod-template-hash=7ff6f44678
revese=deploy-v1.1
Controlled By: ReplicaSet/my-deploy-7ff6f44678
Containers:
my-container:
Container ID: docker://xx
Image: ikubernetes/myapp:v2
还原版本
]# kubectl rollout undo deployment my-deploy --to-revision=1
deployment.apps/my-deploy rolled back
]# kubectl describe pods my-deploy-5fbb68fb8c-2b5xm
Image: ikubernetes/myapp:v1 # 此时在查看就是v1版本了
# 需要注意的是 如果还原了1，那么上一版本就是还原前的版本
]# kubectl rollout history deployment my-deploy
deployment.apps/my-deploy
REVISION CHANGE-CAUSE
2 <none>
3 <none>
# 查看rs的版本
]# kubectl get rs -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
my-deploy-5fbb68fb8c 4 4 4 3h54m my-container ikubernetes/myapp:v1 app=my-deploy,pod-template-hash=5fbb68fb8c,revese=deploy-v1.1
my-deploy-7ff6f44678 0 0 0 121m my-container ikubernetes/myapp:v2 app=my-deploy,pod-template-hash=7ff6f44678,revese=deploy-v1.1
三、daemonSet
- 要求在集群的每一个节点或符合选择器要求的节点运行，并且只运行一个pod副本，
- 通常用于实现系统级的管理功能，比如ELK服务
- daemonSet也是通过标签选择器来判定每一个节点的运行状态。
- **特性：**服务是无状态的，服务必须是守护进程
在整个集群的每一个节点上，只运行某个指定pod的一个并且只能是一个副本或者是集群中某些符合选择器的节点上的某一个副本， 用于实现系统级的管理功能，可以直接把节点上的某个目录做为存储卷关连至某个Pod中
# 查看创建的头部信息
~]# kubectl explain ds
KIND: DaemonSet
VERSION: apps/v1
3.1、参数说明
- minReadySeconds <integer> # 最少的准备节点数
- revisionHistoryLimit <integer> # 保存支持历史版本数， 默认10个
- selector <Object> -required- # 选择器
- template <Object> -required- # 模板对象
- updateStrategy <Object> # 更新策略
- RollingUpdate： # 删一个更新一个
- OnDelete： # 删除更新
- 在yaml配置文件中 通 — 分段，在一个配置文件中可以定义多个资源对象
3.2、demo
3.1、创建yaml
]# cat daemon.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis
labels:
app: redis-v4
release: stable
spec:
replicas: 1
selector:
matchLabels:
app: my-redis
release: base01
template:
metadata:
name: con-redis
labels:
app: my-redis
release: base01
spec:
containers:
- name: redis
image: redis:4.0.14
imagePullPolicy: IfNotPresent
ports:
- name: redis # expose端口 定义别名
containerPort: 6379 # 端口号 6379
livenessProbe: # 存活性探测
tcpSocket:
port: 6379 # 监听6379端口
--- # 分段，可以用于定义多个资源
apiVersion: apps/v1
kind: DaemonSet # 一个节点生成一个副本， 无需在次定义副本数 replicas
metadata:
name: daemons
namespace: default
labels:
app: daemons
release: stable
spec:
revisionHistoryLimit: 5 # 定义最多5个历史版本，默认10个
selector: # 二元素-选择器
matchLabels:
app: daemon-v1
release: base-v1
template: # 二元素-模板
metadata:
name: my-node
namespace: default
labels:
app: daemon-v1
release: base-v1
spec:
containers:
- name: my-con
image: ikubernetes/filebeat:5.6.5-alpine
imagePullPolicy: IfNotPresent
env:
- name: REDIS_HOST # 定义往哪个redis中发送日志
value: redis.default.svc.cluster.local
3.2、生成
]# kubectl apply -f daemon.yaml
deployment.apps/redis created
daemonset.apps/daemons created
# 定义了 name: REDIS_HOST， 名称为redis, dns解析默认后缀 default.svc.cluster.local
]# kubectl expose deployment redis --port=6379
service/redis exposed
# 查看expose端口以及名称
]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
redis ClusterIP 10.109.181.86 <none> 6379/TCP 2s
# 连接至daemon节点查看解析是否成功
]# kubectl exec -it daemons-5x2j8 /bin/sh
Name: redis.default.svc.cluster.local
Address 1: 10.109.181.86 redis.default.svc.cluster.local
3.3、查看资源
# daemonSet资源，查看简写就是ds
]# kubectl get ds
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemons 2 2 2 2 2 <none> 9m56s
# 查看pods分别在哪个节点中
]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
daemons-5x2j8 1/1 Running 0 11m 10.244.1.67 node1
daemons-f2d9g 1/1 Running 0 11m 10.244.2.59 node2
# 查看pods节点信息
]# kubectl describe pods daemons-f2d9g
Name: daemons-f2d9g
Node: node2/192.168.9.32
Labels: app=daemon-v1
controller-revision-hash=5f9fdbdb4c
pod-template-generation=1
release=base-v1
Annotations: <none>
Status: Running
IP: 10.244.2.59
Controlled By: DaemonSet/daemons
3.4、操作资源
]# kubectl get ds
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemons 2 2 2 2 2 <none> 39m
# 升级版本
]# kubectl set image daemonset daemons my-con=ikubernetes/filebeat:5.6.6-alpine
# 设置属性 方法 ds名称 container名称=image版本
daemonset.apps/daemons image updated
# 查看版本 升级成功
]# kubectl describe pods daemons-vzhgk
Name: daemons-vzhgk
Image: ikubernetes/filebeat:5.6.6-alpine
# 查看升级版本
]# kubectl rollout history daemonset daemons
daemonset.apps/daemons
REVISION CHANGE-CAUSE
1 <none>
2 <none>
]# kubectl rollout history daemonset daemons --revision=1
daemonset.apps/daemons with revision #1
Containers:
my-con:
Image: ikubernetes/filebeat:5.6.5-alpine
Environment:
REDIS_HOST: redis.default.svc.cluster.local
]# kubectl rollout history daemonset daemons --revision=2
daemonset.apps/daemons with revision #2
my-con:
Image: ikubernetes/filebeat:5.6.6-alpine
Environment:
REDIS_HOST: redis.default.svc.cluster.local
3.4.1、删除资源
# 删除由这个yaml创建资源
]# kubectl delete -f daemon.yaml
# 删除ds
]# kubectl delete ds daemons
3.4.2、暂停恢复更新
# 暂停更新 kubwx rollout pause deployment daemons
# 继续升级 kubwx rollout resume deployment daemons
四、Job
Job控制器的主要作用是，一次性就业，非守护进程，它需要在后台运行，任务执行完成之后，就退出，我们正常Pod控制器控制的Pod一旦宕机，会自动重建，这是我们的Deployment、ReplicaSet或者DaeonSet的特性，但是有些任务，比如像备份，我们只执行一次备份任务就行了，那这个时候可以使用我们的Job控制器，所以Job控制器就是用来创建一个或多个Pod，这个Pod就是执行相应的任务，完成之后终止就完了，如果要删除Job，我们会删除这个Pod所做的所有操作；
只要完成就立即退出，不需要重启或重建， 要不要重建pod, 就是任务是否完成, job只是一次性运行
五、Cronjob
周期性运行， 每一次退出都会有正常退出的时间，如果前一次任务执行到了正常退出时间还没有退出，那就可能会有任务丢失的可能性
六、statefulSet
- 管理有状态应用，当节点都有自己的特性时就是有状态应用；
- 每一个pod副本都是被单独管理的，它拥有着自己独有标识和独有数据集；
- 一旦节点故障，加入之前需要做很多的初始化操作
假设有多个集群，而每个集群所提供的资源各不尽相同，statefulset提供了一个封装的控制器，这个封装指的是人为的将手动操作, 复杂的执行逻辑将定义成脚本放置在statefules的模板定义当中，每一个节点故障之后通过脚本将自动恢复 (难度极大)
七、其它控制器
| 其它类型资源 | 说明 |
|---|---|
| TPR (third party Resources) | 第三方资源 1.2+支持, 1.7之后废弃 |
| CDR (curstom Defined Resources) | 用户自定义资源 1.8+ 默认 |
| Operator | 封装运维技能，如etcd |
| helm | 与 linux的yum安装类型，直接安装就不使用在手动创建脚本 |
垃圾收集器
Garbage Collction， 垃圾收集： 当一个Pod控制器终止的时候会将这个控制下面的所有Pod全部回收
每一个依赖性的Object在它的metadata中都有一个ownerReferneces字段,你没定义它也会自动填充, 比如由控制器创建的Pod，那么Pod的ownerReferneces就属于它的控制器,所以任意一个Object终止的时候, 一般都由它的ownerReferneces所指定的对象负责给它进行GC垃圾收集,大多数情况下会自动设置，当然也可以自己指定垃圾收集器，收集的方式一般是通过级联的方式进行的；
一个叫做后台一个叫前台， 通常情况下只要删除Pod控制器, 那么该控制器下的所有Pod都将会被级联删除，当然也可以设置不级联删除，pod控制器删除之后下面的Pod也不会被删除，会转为自助式Pod,没有控制器了
基本上有引用者的时候，删除了引用者，那么被引用的资源会一起删除，而这个级联操作，可以工作为两种模型，就是前台和后台，后台就是删除一个资源的过程不用管，全部会在后台执行，所谓前台就是用户需要等待资源以及被引用的资源一起删除之后再进行下一步的操作，会占用终端；
~]# kubectl explain cj.metadata.ownerReferences
|
| Operator | 封装运维技能，如etcd |
| helm | 与 linux的yum安装类型，直接安装就不使用在手动创建脚本 |
垃圾收集器
Garbage Collction， 垃圾收集： 当一个Pod控制器终止的时候会将这个控制下面的所有Pod全部回收
每一个依赖性的Object在它的metadata中都有一个ownerReferneces字段,你没定义它也会自动填充, 比如由控制器创建的Pod，那么Pod的ownerReferneces就属于它的控制器,所以任意一个Object终止的时候, 一般都由它的ownerReferneces所指定的对象负责给它进行GC垃圾收集,大多数情况下会自动设置，当然也可以自己指定垃圾收集器，收集的方式一般是通过级联的方式进行的；
一个叫做后台一个叫前台， 通常情况下只要删除Pod控制器, 那么该控制器下的所有Pod都将会被级联删除，当然也可以设置不级联删除，pod控制器删除之后下面的Pod也不会被删除，会转为自助式Pod,没有控制器了
基本上有引用者的时候，删除了引用者，那么被引用的资源会一起删除，而这个级联操作，可以工作为两种模型，就是前台和后台，后台就是删除一个资源的过程不用管，全部会在后台执行，所谓前台就是用户需要等待资源以及被引用的资源一起删除之后再进行下一步的操作，会占用终端；
~]# kubectl explain cj.metadata.ownerReferences
K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容
更多推荐
0
0- 0
已为社区贡献6条内容
所有评论(0)