标签：周期性 -name skipped 节奏 out exe resolve logging 不可用
目录
Kubernetes中内建了很多controller（控制器），这些相当于?个状态机，?来控制Pod的具体状态和?为。
Pod控制器有多种类型：
ReplicaSet：它的核心作用是代用户创建指定数量的Pod副本，并确定Pod副本一直处于满足用户期望数量的状态，多退少补，同时支持扩缩容机制。主要有三个组件：
Deployment：工作在ReplicaSet之上，用于管理无状态应用，除了ReplicaSet的机制，还增加了滚动更新和回滚功能，提供声明式配置。
DaemonSet：用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如ELK服务。要求：服务是无状态的；服务必须是守护进程
Job：：只要完成就立即退出，不需要重启或重建。
Cronjob：周期性任务控制，不需要持续后台运行。
StatefulSet：管理有状态应用，如mysql，redis等。
ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收。
虽然ReplicaSet可以独立使用，但一般还是建议使用 Deployment 来自动管理ReplicaSet，这样就无需担心跟其他机制的不兼容问题（比如ReplicaSet不支持rolling-update但Deployment支持）。
举例
[root@master ~]# kubectl explain rs
[root@master manifests]# vim rs-demo.yaml
apiVersion: apps/v1 #群组/版本
kind: ReplicaSet #类型 注意大小写
metadata: #元数据
name: myapp
namespace: default
spec:
replicas: 2 #定义ReplicaSet副本数量
selector: #定义选择器
matchLabels: #匹配 ，创建的模板的标签需要包含此处的标签，不然无法被创建
app: myapp
release: canary
template: #定义模板
metadata: #模板元数据
name: myapp-pod #此处名称定义没有用，被控制器创建的pod都会以控制器的名称后加随机字符串来命名
labels: #此处要包含replicaset处定义的标签选择器
app: myapp
release: canary
spec:
containers: #定义模板的容器
- name: myapp-container
image: ikubernetes/myapp:v1
ports: #端口
- name: http
containerPort: 80
#运行后验证
[root@master manifests]# kubectl create -f rs-demo.yaml
replicaset.apps/myapp created
[root@master manifests]# kubectl get rs #replicaset 简写rs
NAME DESIRED CURRENT READY AGE
client-f5cdb799f 1 1 1 3d19h
myapp 2 2 2 10s
nginx-deploy-84cbfc56b6 1 1 1 3d23h
#查看pod
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
client-f5cdb799f-pklmc 1/1 Running 0 3d19h
myapp-fxmjz 1/1 Running 0 59s
myapp-hxvnz 1/1 Running 0 59s
nginx-deploy-84cbfc56b6-tcssz 1/1 Running 0 3d22h
pod-demo 2/2 Running 7 2d22h
poststart-pod 1/1 Running 1 2d16h
readiness-httpget-pod 1/1 Running 0 2d16h
#可以使用kubectl describe pods <POD_NAME>来查看详细信息修改Pod的副本数量：
[root@master manifests]# kubectl edit rs myapp
replicas: 5
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
client-f5cdb799f-pklmc 1/1 Running 0 3d19h
myapp-64qnb 1/1 Running 0 9s
myapp-fxmjz 1/1 Running 0 3m53s
myapp-hdv9c 1/1 Running 0 9s
myapp-hxvnz 1/1 Running 0 3m53s
myapp-mwb27 1/1 Running 0 9s
nginx-deploy-84cbfc56b6-tcssz 1/1 Running 0 3d23h
pod-demo 2/2 Running 7 2d22h
poststart-pod 1/1 Running 1 2d16h
readiness-httpget-pod 修改Pod的镜像版本：
[root@master manifests]# kubectl edit rs myapp
- image: ikubernetes/myapp:v2此时查看原来存在的pod副本还是v1版本，只有重建后的pod才会是V2版本。
kubectl delete -f *** && kube create -f &&
Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新。
只需要在 Deployment 中描述想要的目标状态，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。也可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。
典型的用例如下：
清除旧的不必要的 ReplicaSet。
[root@master ~]# kubectl explain deploy.spec.
KIND: Deployment
VERSION: extensions/v1beta1 #现在最新式apps/v1
minReadySeconds <integer>
paused <boolean> #暂停
progressDeadlineSeconds <integer>
replicas <integer> #replicas
revisionHistoryLimit <integer> #保存历史版本数量，用于回滚，默认10
rollbackTo <Object> #回滚
selector <Object> #选择器，和replicaset的一样
strategy <Object> #更新策略 rollingUpdate滚动更新和Recreate重建更新，如果使用rollingUpdate，内部还可以定义更新粒度
maxSurge #更新时最多可超出副本数 可以是数量和百分比
maxUnavailable #最大不可用 可以是数量和百分比，和上面的maxSurge不能同为0
template <Object> -required- #模板，和replicaset的一样举例
[root@master manifests]# vim deploy-damo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deploy
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: myapp
release: canary
template:
metadata:
labels:
app: myapp
release: canary
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
[root@master manifests]# kubectl apply -f deploy-damo.yaml
deployment.apps/myapp-deploy createdapply表示声明式创建，也可以用来更新
查看创建结果
[root@master manifests]# kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
myapp-deploy 2/2 2 2 2m31s
[root@master manifests]# kubectl get rs
NAME DESIRED CURRENT READY AGE
myapp-deploy-65df64765c 2 2 2 3m22s
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-deploy-65df64765c-95dwm 1/1 Running 0 3m24s
myapp-deploy-65df64765c-btbhg 1/1 Running 0 3m24s
pod-demo 2/2 Running 8 2d22h
poststart-pod 1/1 Running 2 2d17h
readiness-httpget-pod 1/1 Running 0 2d17h直接编辑deploy-damo.yaml，副本数修改为4，然后使用kubectl apply -f 更新 也可以使用-w 监控实时更新
[root@master manifests]# vim deploy-damo.yaml
replicas: 4
[root@master manifests]# kubectl apply -f deploy-damo.yaml
deployment.apps/myapp-deploy configured再次查看
[root@master manifests]# kubectl get rs,deploy,pods
NAME DESIRED CURRENT READY AGE
replicaset.extensions/myapp-deploy-65df64765c 4 4 4 6m53s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.extensions/myapp-deploy 4/4 4 4 6m53s
NAME READY STATUS RESTARTS AGE
pod/myapp-deploy-65df64765c-8q8bq 1/1 Running 0 31s
pod/myapp-deploy-65df64765c-95dwm 1/1 Running 0 6m53s
pod/myapp-deploy-65df64765c-btbhg 1/1 Running 0 6m53s
pod/myapp-deploy-65df64765c-x742g 1/1 Running 0 31s
pod/pod-demo 2/2 Running 8 2d22h
pod/poststart-pod 1/1 Running 2 2d17h
pod/readiness-httpget-pod 1/1 Running 0 2d17h每次使用apply改变的信息都会被保存在annotations里面。
[root@master manifests]# kubectl describe deploy myapp-deploy
Annotations: deployment.kubernetes.io/revision: 1
kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"name":"myapp-deploy","namespace":"default"},"spec":{"replicas":4...
StrategyType: RollingUpdate #默认滚动策略
RollingUpdateStrategy: 25% max unavailable, 25% max surge #更新策略25% 低于1补为1，如果只是更新模板的image 可以使用kubectl set image命令
[root@master manifests]# kubectl set image deployment/myapp-deploy myapp=ikubernetes/myapp:v2如果修改其他配置，例如修改副本数量，滚动更新策略等，可以使用kubectl patch 打补丁后面使用对象的jason格式内容
[root@master ~]# kubectl patch deployment myapp-deploy -p '{"spec":{"replicas":5}}'
[root@master ~]# kubectl patch deployment myapp-deploy -p '{"spec":{"strategy":{"rollingupdate":{"maxsurge“:1,"maxUnavailable":0}}}}'Deployment控制器支持自定义控制更新过程中的滚动节奏，如“暂停(pause)”或“继续(resume)”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布（Canary Release），如下：
#更新deloyment的v3版本，并配置暂停deployment
[root@master manifests]# kubectl set image deployment myapp-deploy myapp=ikubernetes/myapp:v3 && kubectl rollout pause deployment myapp-deploy
deployment.extensions/myapp-deploy image updated
deployment.extensions/myapp-deploy paused
#查看
[root@master ~]# kubectl get pod -w
NAME READY STATUS RESTARTS AGE
myapp-deploy-65df64765c-48bjw 1/1 Running 0 8m2s
myapp-deploy-65df64765c-5qd4x 1/1 Running 0 18s
myapp-deploy-65df64765c-w4htd 1/1 Running 0 8m2s
pod-demo 2/2 Running 8 2d23h
poststart-pod 1/1 Running 3 2d17h
readiness-httpget-pod 1/1 Running 0 2d18h
myapp-deploy-548f47d899-cbhsf 0/1 Pending 0 0s
myapp-deploy-548f47d899-cbhsf 0/1 Pending 0 0s
myapp-deploy-548f47d899-cbhsf 0/1 ContainerCreating 0 0s
myapp-deploy-548f47d899-cbhsf 1/1 Running 0 1s此时只有一个pod版本更新为V3版本
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-deploy-548f47d899-cbhsf 1/1 Running 0 49s
myapp-deploy-65df64765c-48bjw 1/1 Running 0 9m2s
myapp-deploy-65df64765c-5qd4x 1/1 Running 0 78s
myapp-deploy-65df64765c-w4htd 1/1 Running 0 9m2s
pod-demo 2/2 Running 8 2d23h
poststart-pod 1/1 Running 3 2d17h
readiness-httpget-pod 1/1 Running 0 2d18h确保更新的pod没问题了，继续更新
[root@master manifests]# kubectl rollout resume deployment myapp-deploy
deployment.extensions/myapp-deploy resumed
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-deploy-548f47d899-5rdgh 1/1 Running 0 59s
myapp-deploy-548f47d899-cbhsf 1/1 Running 0 2m54s
myapp-deploy-548f47d899-prvpl 1/1 Running 0 57s
pod-demo 2/2 Running 8 2d23h
poststart-pod 1/1 Running 3 2d17h
readiness-httpget-pod 1/1 Running 0 2d18h也可以使用kubectl rollout status <TYPE> <TYPE_NAME>监控
[root@master ~]# kubectl rollout status deployment myapp-deploy
deployment "myapp-deploy" successfully rolled out默认情况下，kubernetes 会在系统中保存前两次的 Deployment 的 rollout 历史记录，以便可以随时回退（您可以修改revision history limit来更改保存的revision数）。
注意： 只要 Deployment 的 rollout 被触发就会创建一个 revision。也就是说当且仅当 Deployment 的 Pod template（如.spec.template）被更改，例如更新template 中的 label 和容器镜像时，就会创建出一个新的 revision。
其他的更新，比如扩容 Deployment 不会创建 revision——因此我们可以很方便的手动或者自动扩容。这意味着当您回退到历史 revision 时，只有 Deployment 中的 Pod template 部分才会回退。
[root@master ~]# kubectl rollout history deploy myapp-deploy #查看升级记录
deployment.extensions/myapp-deploy
REVISION CHANGE-CAUSE
9 <none>
10 <none>这里在创建deployment时没有增加--record参数，所以并不能看到revision的变化。在创建 Deployment 的时候使用了--record参数可以记录命令，就可以方便的查看每次 revision 的变化。
查看单个revision的详细信息：
[root@master ~]# kubectl rollout history deployment/myapp-deploy --revision=10回滚历史版本,默认是上一个版本
[root@master ~]# kubectl rollout undo deployment/myapp-deploy
deployment.extensions/myapp-deploy rolled back使用 --to-revision参数指定某个历史版本：
[root@master ~]# kubectl rollout undo deployment/myapp-deploy --to-revision=11
deployment.extensions/myapp-deploy skipped rollback (current template already matches revision 11)DaemonSet确保全部（或者一些）Node上运行一个Pod的副本。当有Node加入集群时也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。
DaemonSet 的一些典型用法：
一个简单的用法是，在所有的 Node 上都存在一个 DaemonSet，将被作为每种类型的 daemon 使用。 一个稍微复杂的用法可能是，对单独的每种类型的 daemon 使用多个 DaemonSet，但具有不同的标志，和/或对不同硬件类型具有不同的内存、CPU要求。
[root@master ~]# kubectl explain ds.spec.
KIND: DaemonSet
minReadySeconds <integer>
revisionHistoryLimit <integer>
selector <Object>
template <Object> -required-
templateGeneration <integer>
updateStrategy <Object>[root@master manifests]# vim ds-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis
namespace": default
spec:
replicas: 1
selector:
matchLabels:
app: redis
role: logstore
template:
metadata:
labels:
app: redis
role: logstore
spec:
containers:
- name: redis
image: redis:4.0-alpine
ports:
- name: redis
containerPort: 6379
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: filebeat-ds
namespace: default
spec:
selector:
matchLabels:
app: filebeat
release: stable
template:
metadata:
labels:
app: filebeat
release: stable
spec:
containers:
- name: filebeat
image: ikubernetes/filebeat:5.6.5-alpine
env:
- name: REDIS_HOST
value: redis.default.svc.cluster.local
- name: REDIS_LOG_LEVEL
value: info创建并暴漏端口
[root@master manifests]# kubectl apply -f ds-demo.yaml
deployment.apps/redis created
daemonset.apps/filebeat-ds created
[root@master manifests]# kubectl expose deploy redis --port=6379
service/redis exposed
[root@master manifests]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 4d19h
myapp NodePort 10.104.138.182 <none> 80:30298/TCP 3d21h
nginx ClusterIP 10.98.2.12 <none> 80/TCP 4d
redis ClusterIP 10.97.149.76 <none> 6379/TCP 15s测试redis是否收到日志
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
filebeat-ds-28kmv 1/1 Running 0 48s
filebeat-ds-wmlzj 1/1 Running 0 48s
myapp-deploy-65df64765c-9g9bv 1/1 Running 0 29m
myapp-deploy-65df64765c-ll8bk 1/1 Running 0 29m
myapp-deploy-65df64765c-xd2kn 1/1 Running 0 29m
pod-demo 2/2 Running 9 3d
poststart-pod 1/1 Running 3 2d18h
readiness-httpget-pod 1/1 Running 0 2d18h
redis-76c85b5744-7zt7l 1/1 Running 0 48s
#进入redis
[root@master manifests]# kubectl exec -it redis-76c85b5744-7zt7l -- /bin/sh
/data # netstat -lnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN
tcp 0 0 :::6379 :::* LISTEN
/data # nslookup redis.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolve
Name: redis.default.svc.cluster.local
Address 1: 10.97.149.76 redis.default.svc.cluster.local
#由于redis在filebeat后面才启动，日志可能已经发走了，所以查看key为空
/data # redis-cli -h redis.default.svc.cluster.local
redis.default.svc.cluster.local:6379> keys *
(empty list or set)
#进入filebeat容器
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
filebeat-ds-28kmv 1/1 Running 0 4m48s
filebeat-ds-wmlzj 1/1 Running 0 4m48s
myapp-deploy-65df64765c-9g9bv 1/1 Running 0 33m
myapp-deploy-65df64765c-ll8bk 1/1 Running 0 33m
myapp-deploy-65df64765c-xd2kn 1/1 Running 0 33m
pod-demo 2/2 Running 9 3d
poststart-pod 1/1 Running 3 2d18h
readiness-httpget-pod 1/1 Running 0 2d18h
redis-76c85b5744-7zt7l 1/1 Running 0 4m48s
[root@master manifests]# kubectl exec -it filebeat-ds-28kmv -- /bin/sh
#查看filebeat配置文件
filebeat.registry_file: /var/log/containers/filebeat_registry
filebeat.idle_timeout: 5s
filebeat.spool_size: 2048
logging.level: info
filebeat.prospectors:
- input_type: log
paths:
- "/var/log/containers/*.log"
- "/var/log/docker/containers/*.log"
- "/var/log/startupscript.log"
- "/var/log/kubelet.log"
- "/var/log/kube-proxy.log"
- "/var/log/kube-apiserver.log"
- "/var/log/kube-controller-manager.log"
- "/var/log/kube-scheduler.log"
- "/var/log/rescheduler.log"
- "/var/log/glbc.log"
- "/var/log/cluster-autoscaler.log"
symlinks: true
json.message_key: log
json.keys_under_root: true
json.add_error_key: true
multiline.pattern: '^\s'
multiline.match: after
document_type: kube-logs
tail_files: true
fields_under_root: true
output.redis:
hosts: ${REDIS_HOST:?No Redis host configured. Use env var REDIS_HOST to set host.}
key: "filebeat"
DaemonSet有两种更新策略类型：
[root@master ~]# kubectl explain ds.spec.updateStrategy.type.
KIND: DaemonSet
VERSION: extensions/v1beta1
FIELD: type <string>
DESCRIPTION:
Type of daemon set update. Can be "RollingUpdate" or "OnDelete". Default is
OnDelete.要启用DaemonSet的滚动更新功能，必须将其设置 .spec.updateStrategy.type为RollingUpdate。
查看当前的更新策略：
[root@master manifests]# kubectl get ds/filebeat-ds -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'
RollingUpdate更新DaemonSet模板
对RollingUpdateDaemonSet的任何更新都.spec.template将触发滚动更新。这可以通过几个不同的kubectl命令来完成。
1) 声明式命令方式： 修改配置文件后使用kubectl apply更新
2）补丁式命令方式：kubectl edit ds/filebeat-ds
kubectl patch ds/filebeat-ds -p=<strategic-merge-patch>
仅仅更新容器镜像还可以使用以下命令：
kubectl set image ds/<daemonset-name> <container-name>=<container-new-image>
对filebeat-ds的镜像进行版本更新
[root@master manifests]# kubectl set image ds filebeat-ds filebeat=ikubernetes/filebeat:5.6.6-alpine
daemonset.extensions/filebeat-ds image updated
[root@master manifests]# kubectl get pods -w
NAME READY STATUS RESTARTS AGE
filebeat-ds-28kmv 1/1 Running 0 21m
filebeat-ds-wmlzj 0/1 Terminating 0 21m
myapp-deploy-65df64765c-9g9bv 1/1 Running 0 50m
myapp-deploy-65df64765c-ll8bk 1/1 Running 0 50m
myapp-deploy-65df64765c-xd2kn 1/1 Running 0 50m
pod-demo 2/2 Running 10 3d
poststart-pod 1/1 Running 4 2d18h
readiness-httpget-pod 1/1 Running 0 2d19h
redis-76c85b5744-7zt7l 1/1 Running 0 21m
filebeat-ds-wmlzj 0/1 Terminating 0 21m
filebeat-ds-wmlzj 0/1 Terminating 0 21m
filebeat-ds-j69gd 0/1 Pending 0 0s
filebeat-ds-j69gd 0/1 Pending 0 0s
filebeat-ds-j69gd 0/1 ContainerCreating 0 0s
filebeat-ds-j69gd 1/1 Running 0 14s
filebeat-ds-28kmv 1/1 Terminating 0 21m
filebeat-ds-28kmv 0/1 Terminating 0 21m
filebeat-ds-28kmv 0/1 Terminating 0 21m
filebeat-ds-28kmv 0/1 Terminating 0 21m
filebeat-ds-p5r4n 0/1 Pending 0 0s
filebeat-ds-p5r4n 0/1 Pending 0 0s
filebeat-ds-p5r4n 0/1 ContainerCreating 0 0s
filebeat-ds-p5r4n 1/1 Running 0 13s从上面的滚动更新，可以看到在更新过程中，是先终止旧的pod，再创建一个新的pod，逐步进行替换的，这就是DaemonSet的滚动更新策略。
https://www.cnblogs.com/linuxk
马永亮. Kubernetes进阶实战 (云计算与虚拟化技术丛书)
Kubernetes-handbook-jimmysong-20181218
Kubernetes之Pod控制器，ReplicaSet，Deployment，DaemonSet
标签：周期性 -name skipped 节奏 out exe resolve logging 不可用
原文地址：https://www.cnblogs.com/wlbl/p/10652892.html
