Pod API属性详解
Pod是k8s集群中的最小编排单位。将这个设计落实到API对象上，容器就成了Pod属性里一个普通的字段。那么到底哪些属性属于Pod对象，哪些属性属于容器的呢？先看下面的一段描述：
假如把Pod看成传统环境里的"机器"、那么容器就是运行在这个"机器"里的"用户程序"，这样很多关于Pod对象的设计就非常容易理解了。凡是调度、网络、存储，以及安全相关的属性，基本上是Pod级别的。他们的共同特征是：描述的是"机器"这个整体，而不是里面运行的"程序"。比如：
# 配置这个"机器"的网卡——Pod 的网络定义
# 配置这个"机器"的磁盘——Pod 的存储定义
# 配置这个"机器"的防火墙——Pod 的安全定义
# 这台"机器"运行在哪个服务器之上——Pod 的调度
关于标签
所有的资源都可以设置标签，目的就是为了给资源贴标识符，使用时用选择器调用标签，用到标签的地方:
后端有以副本形式存在的Pod，这么多副本最好做负载均衡，此时就在前面创建一个service，一般情况下是先创建rc,然后创建service，创建完成后需要将service和后端的rc关联到一起，关联到一起就是用标签选择器关联的,即使不需要标签也最好设置一个能用的标签，标签可以由多个字典元素组成. 标签的格式: name:value,一个键值对表示一个标签，调用时一起调用，例如: 做nginx，这里是众多nginx的第一个,故可以设置这个标签由两个字典元素组成，标签可以有多行，但标签的值不能是纯数字.
Pod级别的相关属性
凡是跟Namespace都是Pod级别的,比如，容器的Linux Namespace、容器共享宿主机的 Namespace
原因：Pod 的设计就是要让它里面的容器尽可能多地共享Linux Namespace，仅保留必要的隔离和限制能力。如此Pod模拟出的效果才能跟虚拟机里程序间的关系非常类似.
apiVersion
除了deployment是v1的升级版，其他的基本都是v1。 # kubectl api-versions
kind
指定这个API对象的资源类型: Pod、Deployment、Job、Ingress、Service等，资源类型的首字母需大写.
metadata
描述创建资源的属性，比如Pod的名称，namspace、标签等信息.
spec
specification of the resource content: 指定该资源的内容，包括一些container,storage,volume以及其他k8s需要的参数,以及诸如是否在容器失败时重新启动容器的属性，可在特定Kubernetes API找到完整的Kubernetes Pod属性.
Spec常用字段
# Pod资源：
spec.containers <[]object >
spec:
containers:
- name <string>
image <string> # 仓库路径,项目名称,用户,镜像名称,镜像标签
ports:
- name: http
containerPort: 80
- name: https
containerPort: 443
imagePullPolicy: IfNotPresent # 镜像获取策略
# 修改镜像中的默认应用:
command,args
# 标签<最多六十三个字符>
key=value
key: 字符，数字，_-,.，# 只能以字母数字开头及结尾
value: 可以为空， # 只能字母或者数字开头及结尾，中间可使用:
# Always,Never,IfNotPresent
# Always: 本地不管有没有镜像都是要到仓库去下载，本地无论有还是没有到要去仓库下载，就算本地有镜像他也不用:
# 虽然会导致容器启动变慢，但是可以防止被人恶意修改镜像不被中招：
# Never: 永远不下载，需要用户手动去拖镜像,镜像一旦创建，不允许被更改，一旦编辑就报错，除非删除再创建:
# IfNotPresent: 本地不存在就去下载:
# 如果是latest标签就是Always，否则就是IfNotPresent
Example1(给Pod打标签示例)
cat demo1-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-demo
namespace: default
labels:
app: myapp
tier: frontend
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
- name: https
containerPort: 443
- name: busybox
image: busybox:latest
imagePullPolicy: IfNotPresent
command:
- "/bin/sh"
- "-c"
- "sleep 3600"
查看Pod标签
[root@master YAML]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-test2 1/1 Running 0 37m run=nginx-test2
pod-demo 2/2 Running 0 2m30s app=myapp,tier=frontend
[root@master YAML]# kubectl get pods -L app
# 显示指定资源类别对象下所有标签的值.
NAME READY STATUS RESTARTS AGE APP
nginx-test2 1/1 Running 0 36m
pod-demo 2/2 Running 0 71s myapp
[root@master YAML]# kubectl get pods -l app
# -l才是过滤
NAME READY STATUS RESTARTS AGE
pod-demo 2/2 Running 0 84s
修改标签
# 如果期望将金丝雀改变为稳定版,觉得版本发布没问题,可以改过去
kubectl label pods pod-demo release=canar
# 标签不能重名，如果需要重名加上--overwrite覆盖即可.
kubectl label pod pod-demo release=stable --overwrite
# 修改节点标签
kubectl label nodes node1 disktype=ssd
标签选择器
等值关系: =，==,!=都表示等值关系
kubectl get pods -l release=stable,app --show-labels
NAME READY STATUS RESTARTS AGE LABELS
pod-demo 2/2 Running 0 11m app=myapp,release=stable,tier=frontend
# 集合关系:
# KEY in (VALUE1,VALUE2...)
# KEY notin (VALUE1,VALUE2...)
nodeSelector <map[string]string>能影响Pod调度算法
如果我们需要对一些节点拥有ssd硬盘的机器做监控就需要将相应节点打上ssd标签.然后通过标签选择器将Pod运行在指定节点上.
我们在之前那个demo-pod配置文件加上一个字段即可.
我们先给节点打标签
kubectl get nodes --show-labels
NAME STATUS ROLES AGE VERSION LABELS
master Ready master 43h v1.17.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=master,kubernetes.io/os=linux,node-role.kubernetes.io/master=
node1 Ready <none> 43h v1.17.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux
node2 Ready <none> 43h v1.17.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2,kubernetes.io/os=linux
kubectl label nodes node1 disktype=ssd
node/node1 labeled
kubectl get nodes --show-labels |grep disktype=ssd
node1 Ready <none> 43h v1.17.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux
我们重新修改下demo1-pod.yaml
cat demo1-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-demo
namespace: default
labels:
app: myapp
tier: frontend
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
- name: https
containerPort: 443
- name: busybox
image: busybox:latest
imagePullPolicy: IfNotPresent
command:
- "/bin/sh"
- "-c"
- "sleep 3600"
nodeSelector:
disktype: ssd
kubectl create -f demo1-pod.yaml
kubectl get pods -o wide
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-test2 1/1 Running 0 49m 10.244.0.18 master <none> <none>
pod-demo 2/2 Running 0 53s 10.244.1.15 node1 <none> <none>
annotations:
与label不同地方在于，他不能用于挑选资源对象，没有字符限制，仅用于对象提供“元数据”和
注解.
cat demo1-pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: pod-demo
namespace: default
labels:
app: myapp
tier: frontend
annotations:
youmen.com/create-by: "youmen"
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
- name: https
containerPort: 443
- name: busybox
image: busybox:latest
imagePullPolicy: IfNotPresent
command:
- "/bin/sh"
- "-c"
- "sleep 3600"
nodeSelector:
disktype: ssd
kubectl create -f pod-demo.yaml
kubectl describe pods pod-demo |grep Annotations
Annotations: youmen.com/create-by: youmen
Pod生命周期
Pod生命周期状态
Pending: # 调度尚未完成
Running: # 正在运行
Failed: # 失败
Succeded: # 成功
Unknown: # 未知状态.
创建Pod过程
当用户创建Pod时，这个请求提交给API Server,他先将状态保存在etcd中，APIServer，接下来会请求Scheduler进行调度，如果调度成功后会将结果保存在etcd资源，更新到etcd状态资源中，随后目标节点调到node1上，根据那个清单创建所需要的Pod.
Probe机制
# Pod生命周期的重要行为:
# 初始化容器:
# 容器探测:
# 1. lieness probe: <是否存活>
# 如果检查失败，杀死容器,根据Pod的restartPolicy来操作
# 2. readiness probe: <是否就绪>
# 如果检查失败，Kubernetes会把Pod从service endpoints中删除.
# 两种都支持三种探测行为:
# 1. exec: 执行自定义命令，看返回状态码是否为0
# 2. tcpSocket: 向指定TCP套接字发请求，端口发请求,发起
# 3. httpGet: 向指定http服务发请求，应用层get,url响应码.
# 存活性探测: 主要用于判定主容器是否处于运行状态
# 就绪性探测: 适用于判定容器中主进程是否处于就绪并可以对外进行服务.
readiness probe:
我们为动态有生命周期Pod提供一个固定的端点，service用标签选择器关联到各个Pod资源:
此处有一个问题，如果有一个新的Pod，这个新Pod刚好符合service条件加入到后端，而有新请求进来就会被调度到新的Pod，但这个时候新Pod里面服务很有可能还没有就绪，里面文件还没有展开，而这个时候去访问就有可能出现访问失败，如果不做就绪性探测，Pod一创建就关联到service后出现大量访问失败:
restartPolicy: <重启策略>
Always,UnFailure,Never,Default to Always.
Always: # 一旦Pod中容器挂了就地将他重启.
UnFailure: # 状态为错误才重启，正常终止不重启: # 延时重启
Never: # 挂了就挂了，从来不重启.
Example
cat pod-probe.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /index.html
port: 80
kubectl logs nginx-pod
10.244.3.1 - - [22/Dec/2019:11:03:04 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.17" "-"
10.244.3.1 - - [22/Dec/2019:11:03:14 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.17" "-"
10.244.3.1 - - [22/Dec/2019:11:03:24 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.17" "-"
10.244.3.1 - - [22/Dec/2019:11:03:34 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.17" "-"
# 我们可以看到每十秒都会进行一次测试
# 接下来我们把那个页面删除，看会怎么样
kubectl exec -it nginx-pod /bin/bash
rm -rf usr/share/nginx/html/index.html
# 然后我们去事件里面看看他做了什么处理.
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 3m35s default-scheduler Successfully assigned default/nginx-pod to node1
Normal Pulling 43s (x2 over 3m34s) kubelet, node1 Pulling image "nginx"
Warning Unhealthy 43s (x3 over 63s) kubelet, node1 Liveness probe failed: HTTP probe failed with statuscode: 404
Normal Killing 43s kubelet, node1 Container nginx failed liveness probe, will be restarted
Normal Pulled 21s (x2 over 3m14s) kubelet, node1 Successfully pulled image "nginx"
Normal Created 21s (x2 over 3m14s) kubelet, node1 Created container nginx
Normal Started 21s (x2 over 3m14s) kubelet, node1 Started container nginx
# 我们可以看到当检测不到报错的话，他会自己重新创建一个新镜像.此处只是个页面检测,
# 如果是其他类型服务也可以使用TCP套接字做检测.
Pod的排错
kubectl describe TYPE NAME_PREFIX
kubectl logs nginx-xx
kubectl exec -it nginx-xx bash or /bin/bash
许多资源支持内嵌字段
matchLabels: 直接给定键值
matchExpresslons: 基于给定的表达式来定义使用标签选择器,{key:"KEY",operator: "OPERATOR" ,values: [VAL1,VAL2...]}
# 操作符
# In,NotIn: values字段的值必须为空列表.
# Exists，NotExists: values字段的值为空列表.
?
Pod控制器
Pod控制器用于实现代我们管理Pod中间层，帮我们确保Pod是我们所期望的目标状态,如果出现故障，他会尝试重启，如果重启失败，他会尝试重新编排重新构建一个，如果Pod副本数量低于用户定义目标数量，他会自动补全，反之终止多余目标资源
但此处Pod控制器只是一个泛称，包含以下控制器
ReplicaSet控制器(ReplicationController)
核心作用在于代用户创建指定数量的副本，并确保副本数量一直符合用户所定义状态，还支持扩缩容机制
kubernetes不建议我们直接使用ReplicaSet，而是用Deployment,因为它还支持滚动更新，回滚，声明式配置更新
简写为rs
cat rs-demo1.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: myapp
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: myapp
release: canary
template:
metadata:
name: myapp-pod
labels:
app: myapp
release: canary
environment: qa
spec:
containers:
- name: myapp-container
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
# 我们此处的标签尽量条件匹配复杂一点，避免以后创建Pod标签冲突，多退少补
# 如果需要添加副本数量直接edit配置文件即可，最好使用打补丁方式修改.
# 如果需要更新版本，只有重建Pod才能更新成功.
# 还能控制更新节奏，加一个删一个，加一个删两个，加两个删两个.d
# 灰度发布： 删一个创建一个
# 金丝雀发布: 删一个，等过段时间看用户反应，没什么不好的影响全部给升级
# 蓝绿发布： 在创建个RS,改下service匹配条件，让请求都匹配到RS2上.
# Deployment就建构在RS之上.一个Deployment可以管理多个RS，
Deployment控制器
kubernetes不建议我们直接使用ReplicaSet，而是用Deployment,因为它还支持滚动更新，回滚，声明式配置更新,管理无状态非常好
cat pod-deployment.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
ports:
- name: http
containerPort: 80
kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-deploy-7d574d56c7-44mqw 1/1 Running 0 52s
myapp-deploy-7d574d56c7-5msnk 1/1 Running 0 52s
# 此处的5msnk是模板的哈希值.我们可以通过apply增加副本数量，但是后面哈希值不变
kubectl describe deploy myapp-deploy
我们可以实时更新一下
kubectl get pods -l app=myapp -w
NAME READY STATUS RESTARTS AGE
myapp-deploy-7d574d56c7-44mqw 1/1 Running 0 2m56s
myapp-deploy-7d574d56c7-5msnk 1/1 Running 0 2m56s
# 我们再另开一个终端修改配置文件或者打补丁，然后实时查看此处的哈希变化.
kubectl edit deploy myapp-deploy
replicas: 4
- image: ikubernetes/myapp:v2
kubectl get pods -l app=myapp -w
NAME READY STATUS RESTARTS AGE
myapp-deploy-7d574d56c7-44mqw 1/1 Running 0 8m15s
myapp-deploy-7d574d56c7-5msnk 1/1 Running 0 8m15s
myapp-deploy-7d574d56c7-gvl9q 0/1 Pending 0 0s
myapp-deploy-798dc9b584-z7jhh 0/1 Pending 0 0s
myapp-deploy-7d574d56c7-gvl9q 0/1 Pending 0 0s
myapp-deploy-7d574d56c7-nkwt6 0/1 Pending 0 0s
myapp-deploy-798dc9b584-z7jhh 0/1 Pending 0 1s
myapp-deploy-7d574d56c7-nkwt6 0/1 Pending 0 1s
myapp-deploy-7d574d56c7-gvl9q 0/1 ContainerCreating 0 1s
myapp-deploy-7d574d56c7-nkwt6 0/1 ContainerCreating 0 1s
myapp-deploy-798dc9b584-q8fxd 0/1 Pending 0 0s
myapp-deploy-798dc9b584-q8fxd 0/1 Pending 0 0s
myapp-deploy-798dc9b584-z7jhh 0/1 ContainerCreating 0 1s
myapp-deploy-7d574d56c7-gvl9q 0/1 Terminating 0 1s
myapp-deploy-798dc9b584-q8fxd 0/1 ContainerCreating 0 0s
myapp-deploy-7d574d56c7-gvl9q 0/1 Terminating 0 1s
myapp-deploy-7d574d56c7-nkwt6 1/1 Running 0 3s
myapp-deploy-798dc9b584-z7jhh 1/1 Running 0 7s
myapp-deploy-7d574d56c7-nkwt6 1/1 Terminating 0 7s
myapp-deploy-798dc9b584-sjj65 0/1 Pending 0 0s
myapp-deploy-798dc9b584-sjj65 0/1 Pending 0 0s
myapp-deploy-798dc9b584-sjj65 0/1 ContainerCreating 0 0s
myapp-deploy-7d574d56c7-gvl9q 0/1 Terminating 0 8s
myapp-deploy-7d574d56c7-gvl9q 0/1 Terminating 0 8s
myapp-deploy-7d574d56c7-nkwt6 0/1 Terminating 0 8s
myapp-deploy-7d574d56c7-nkwt6 0/1 Terminating 0 9s
myapp-deploy-7d574d56c7-nkwt6 0/1 Terminating 0 9s
myapp-deploy-798dc9b584-sjj65 1/1 Running 0 2s
myapp-deploy-7d574d56c7-44mqw 1/1 Terminating 0 9m13s
myapp-deploy-798dc9b584-rdtmd 0/1 Pending 0 0s
myapp-deploy-798dc9b584-rdtmd 0/1 Pending 0 0s
myapp-deploy-798dc9b584-rdtmd 0/1 ContainerCreating 0 0s
myapp-deploy-7d574d56c7-44mqw 0/1 Terminating 0 9m14s
myapp-deploy-798dc9b584-q8fxd 1/1 Running 0 10s
myapp-deploy-798dc9b584-rdtmd 1/1 Running 0 2s
myapp-deploy-7d574d56c7-5msnk 1/1 Terminating 0 9m15s
myapp-deploy-7d574d56c7-5msnk 0/1 Terminating 0 9m16s
myapp-deploy-7d574d56c7-5msnk 0/1 Terminating 0 9m17s
myapp-deploy-7d574d56c7-5msnk 0/1 Terminating 0 9m17s
myapp-deploy-7d574d56c7-44mqw 0/1 Terminating 0 9m22s
myapp-deploy-7d574d56c7-44mqw 0/1 Terminating 0 9m22s
我们可以查看一下rs，此处有两个版本了，一个v1一个v2
kubectl get rs -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
myapp-deploy-798dc9b584 4 4 4 4m15s myapp ikubernetes/myapp:v2 app=myapp,pod-template-hash=798dc9b584,release=canary
myapp-deploy-7d574d56c7 0 0 0 13m myapp ikubernetes/myapp:v1 app=myapp,pod-template-hash=7d574d56c7,release=canary
# 但是myapp:v1为历史版本，会保留着随时等待被回滚.
kubectl rollout history deployment myapp-deploy
deployment.apps/myapp-deploy
REVISION CHANGE-CAUSE
1 <none>
2 <none>
我们可以使用patch打补丁方式修改实时更新策略
kubectl patch deployment myapp-deploy -p ‘{"spec":{"replicas":5}}‘
# 此时副本数量就为5个了
kubectl describe deployment myapp-deploy # 修改deployment最大不可用和最小保留
kubectl describe deployment myapp-deploy |grep RollingUpdateStrategy
RollingUpdateStrategy: 0 max unavailable, 1 max surge
# 接下来我们修改下镜像版本，然后更新看一看（金丝雀发布）
kubectl set image deployment myapp-deploy myapp=ikubernetes/myapp:v3 && kubectl rollout pause deployment myapp-deploy
deployment.apps/myapp-deploy image updated
deployment.apps/myapp-deploy paused
# 另一个终端使用以下命令实时查看
kubectl get pods -l app=myapp -w
NAME READY STATUS RESTARTS AGE
myapp-deploy-798dc9b584-bcdxf 1/1 Running 0 14m
myapp-deploy-798dc9b584-q8fxd 1/1 Running 0 57m
myapp-deploy-798dc9b584-rdtmd 1/1 Running 0 57m
myapp-deploy-798dc9b584-sjj65 1/1 Running 0 57m
myapp-deploy-798dc9b584-z7jhh 1/1 Running 0 57m
myapp-deploy-5dc9c974d7-qlpmq 0/1 Pending 0 0s
myapp-deploy-5dc9c974d7-qlpmq 0/1 Pending 0 0s
myapp-deploy-5dc9c974d7-qlpmq 0/1 ContainerCreating 0 0s
myapp-deploy-5dc9c974d7-qlpmq 1/1 Running 0 9s
kubectl rollout status deployment myapp-deploy
Waiting for deployment "myapp-deploy" rollout to finish: 1 out of 5 new replicas have been updated...
# 此时我们发现他会一直卡在这一个Pod更新，接下来我们让他全部更新
kubectl rollout resume deployment myapp-deploy
# 我们发现此时有了第三个版本
kubectl get rs -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
myapp-deploy-5dc9c974d7 5 5 5 5m4s myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=5dc9c974d7,release=canary
myapp-deploy-798dc9b584 0 0 0 64m myapp ikubernetes/myapp:v2 app=myapp,pod-template-hash=798dc9b584,release=canary
myapp-deploy-7d574d56c7 0 0 0 73m myapp ikubernetes/myapp:v1 app=myapp,pod-template-hash=7d574d56c7,release=canary
# 接下来我们可以用回滚
kubectl rollout undo deployment myapp-deploy --to-revision=1 # 回滚到第一个版本
kubectl rollout history deployment myapp-deploy
deployment.apps/myapp-deploy
REVISION CHANGE-CAUSE
2 <none>
3 <none>
4 <none> # 此时我们看到已经有第四个版本了,而此时工作的是v1版
curl 10.244.2.20
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
DaemonSet控制器
在集群中每个节点只运行一个Pod副本
也可以根据自己需求，在部分节点运行一个Pod副本
DaemonSet有以下特点
# 1. 一般是无状态的
# 2. 这种服务必须是守护进程，持续运行在后台
Example1
cat pod-ds.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: redis
role: logstor
template:
metadata:
labels:
app: redis
role: logstor
spec:
containers:
- name: redis
image: redis:4.0-alpine
ports:
- name: redis
containerPort: 6379
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: myapp-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
kubectl exec -it redis-646cf89449-b5qkr /bin/bash
Address 1: 10.96.249.167 redis.default.svc.cluster.local
DaemonSet也支持滚动更新
kubectl get ds -o wide
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE CONTAINERS IMAGES SELECTOR
myapp-ds 2 2 2 2 2 <none> 23m filebeat ikubernetes/filebeat:5.6.5-alpine app=filebeat,release=stable
[root@master ~]# kubectl set image daemonsets myapp-ds filebeat=ikubernetes/filebeat:5.6.6-alpine
Example2 (Pod中容器和宿主机共享网络、进程通信和进程PID Namespace)
cat ns1.yaml
apiVersion: v1
kind: Pod
metadata:
name: web-nginx2
spec:
hostNetwork: true
hostIPC: true
hostPID: true
containers:
- name: web-nginx2
image: daocloud.io/library/nginx
- name: shell
image: busybox
stdin: true
tty: true
kubectl apply -f ns1.yaml
kubectl attach -it web-nginx2 -c shell
/ # ps ax |grep network
3522 root 15:32 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --\
kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml \
--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.1
23958 root 0:00 grep network
# Pod中的所有容器直接使用宿主机的网络、直接与宿主机进行IPC通信，且能够看到宿主机正在运行的所有进程
Job
此类控制器主要为了完成指定任务、作业，只要没完成作业就会不断重建直至完成
帮我们确保Pod任务是正常完成的，没有出现什么异常
但是只是一次性任务
也可以使周期性任务，但他们不需要持续在后台运行，CronJob
以上控制器只能针对无状态应用,
StatefulSet
针对每一种服务每一种报错都要定义相应的恢复操作
比如说你Mysql主从节点的从节点宕机了，你要定义很多操作创建一个从节点然后让他们衔接，稍有不慎，整个集群就崩溃了
我们可以通过Operator将一些运维技能给灌进去,但是支持的应用有限
直到后来出现了helm,类似于yum,类似于模板
Example1（Pod中容器共用一个Pid Namespace）
cat ns.yaml
apiVersion: v1
kind: Pod
metadata:
name: web-nginx
spec:
shareProcessNamespace: true
containers:
- name: web-nginx
image: daocloud.io/library/nginx
- name: shell
image: busybox
stdin: true
tty: trdue
# 1、shareProcessNamespace: true表示此Pod中的容器共享PID，即每个容器都能看到其他容器内的进程
# 2. 定义两个容器：一个nginx；一个等同于使用-it选项的容器
此Pod被创建后，就可以使用shell容器的tty跟这个容器进行交互。
kubectl apply -f ns.yaml
kubectl attach -it web-nginx -c shell
If you don‘t see a command prompt, try pressing enter.
/ # ps ax
PID USER TIME COMMAND
1 root 0:00 /pause
6 root 0:00 nginx: master process nginx -g daemon off;
11 101 0:00 nginx: worker process
21 root 0:00 sh
26 root 0:00 ps ax
# 在容器里能同时看到nginx和busybox以及Infra容器的/pause的进程，整个Pod里的每个容器进程对于所有容器来说都是可见的，
# 因为它们共享同一个 PID Namespace。
node的相关属性
nodeName: 这个字段一般由调度器负责设置，用户也可以设置他来‘骗过‘调度器，一旦Pod的这个字段被赋值，k8s就会被认为此Pod已经调度过,调度的结果就是赋值的节点名字，这个做法一般是测试或者调试的时候才会用到，简单来说就是不让调度器去选择此Pod运行在哪个node上，而是用户自行指定该Pod运行的node.
nodeSelector： 和nodeName的作用一样，是一个供用户将Pod与Node进行绑定的字段，例如: 设置Pod永远只能运行在携带了: "Kubernetes.io/hostname: k8s-node1"标签的节点上: 否则，他将调度失败.
Example1(使用nodeSelector指定pod运行的节点)
查看k8s-node1上的标签都有哪些
kubectl describe pod web-nginx |grep ^Labels -C3
Priority: 0
Node: node2/172.19.0.54
Start Time: Thu, 19 Dec 2019 17:45:43 +0800
Labels: <none>
Annotations: <none>
Status: Running
IP: 10.244.1.5
创建一个Pod指定运行在node1上
cat nginx1.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: test-nginx
labels:
web: nginx2
nginx: nginx3
spec:
# nodeName: 192.168.122.5 #也可以使用下面的nodeSelector。
containers:
- name: web-test
image: daocloud.io/library/nginx
ports:
- containerPort: 80
nodeSelector:
kubernetes.io/hostname: node1
kubectl apply -f nginx1.yaml
容器中的hosts文件解析
HostAliases: 定义Pod容器中的/etc/hosts文件，解析主机名，且在k8s中，一定要通过此方法设置hosts文件中的内容，如果直接修改hosts文件，在Pod被删除重建之后，kubelet会自动覆盖被修改的内容
cat nginx2.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: web-nginx3
labels:
web: nginx4
nginx: nginx5
spec:
hostAliases:
- ip: "1.1.1.1"
hostnames:
- "cluster1.com"
- "cluster2.com"
- "cluster3.com"
containers:
- name: web2
image: daocloud.io/library/nginx
ports:
- containerPort: 80
# kubectl apply -f nginx2.yaml
kubectl exec -it web-nginx3 /bin/bash
root@web-nginx3:/# ls
bin dev home lib64 mnt proc run srv tmp var
boot etc lib media opt root sbin sys usr
root@web-nginx3:/# cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
fe00::0 ip6-mcastprefix
fe00::1 ip6-allnodes
fe00::2 ip6-allrouters
10.244.1.6 web-nginx3
# Entries added by HostAliases.
1.1.1.1 cluster1.com cluster2.com cluster3.com
多个ip对应不同域名的写法
spec:
hostAliases:
- ip: "1.1.1.1"
hostnames:
- "cluster1.com"
- ip: "2.2.2.2"
hostnames:
- "cluster2.com"
容器的属性
- 容器是Pod中最重要的字段，有"Containers" 和"Init Containers" 两种写法，内容完全相同.
- Init Containers: 其生命周期会先于所有的容器（即优先启动），并且严格按照定义的顺序执行.
- containers: 指定多个名称表示多个容器，每一个容器都是列表中的一个元素，每一列元素中还会有字典，字典不同的元素表示容器的不同属性，容器可以设置复杂的属性，包括容器启动运行的命令，使用的参数、工作目录以及每次实例化是否拉取新的副本，还可以指定更深入的信息，例如容器的退出日志的位置等. 包括: name、image、command、args、workingDir、ports、env、resource、volumeMounts、livenessProbe、readinessProbe、livecycle、terminationMessagePath、imagePullPolicy、securityContext、stdin、stdinOnce、tty
name：容器的名字，起个有意义的名字
image：容器镜像
command：容器启动运行的命令
args：容器使用的参数
workingDir：容器的工作目录
ports：容器监听的端口
env：定义容器的环境变量，主要是给mysql这种应用使用的spec:containers:env
env:
- name: a # 变量名称
value: "hello" # 变量值，必须加引号
volumeMounts：# 共享卷
imagePullPolicy：# 镜像拉取策略，此属性有bug。
# 默认值Always表示每次创建Pod都重新拉取一次镜像，实际上是镜像在本地无需拉取；
Never：# 不拉取镜像，本地有直接使用，本地不存在就报异常错误
IfNotPresent: # 表示宿主机上不存在这个镜像时才拉取，建议使用。
官方提供的钩子示例**
- 容器成功启动之后，在/usr/share/message中写入了一句“欢迎信息”(PostStart定义)，在这个容器被删除之前，则先调用nginx的退出命令(preStop定义),从而实现容器中的应用从而关闭.
cat message.yaml
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: daocloud.io/library/nginx
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
preStop:
exec:
command: ["/usr/sbin/nginx","-s","quit"]
kubectl apply -f message.yaml
注释
-
postStart: 开始之后执行的动作,虽然理论上是在Docker容器ENTRYPOINT执行之后，但它并不严格保证顺序。即：在postStart启动时，ENTRYPOINT有可能还没有结束。如果postStart执行超时或者错误，k8s会在该Pod的Events中报出该容器启动失败的错误信息，导致Pod也处于失败的状态。
-
preStop：停止之前指定的动作。操作的执行是同步的，所以它会阻塞当前的容器杀死流程，直到这个 Hook定义操作完成之后，才允许容器被杀死。
-
Pod | docker 容器的生命周期
-
Pod声明周期的变化，主要体现在Pod API对象的Status部分，这是除了Metadata和Spec之外的第三个重要字段,其中Pod.status.phase就是Pod的当前状态，有如下几种可能的情况:
-
Pending: 此状态表示Pod的YAML文件已经提交给了kubernetes，API对象已经被创建并保存在Etcd中.但是这个Pod里有些容器因为某种原因不能被顺利创建，比如: 调度不成功. (准备状态: 准备好了就running，准备不好就是failed)
-
Running: 此状态表示Pod已经调度成功，跟一个具体的节点绑定,它包含的容器都已经创建成功,并且至少有一个正在运行中.
-
Succeeded: 此状态表示Pod里的所有容器都正常运行完毕,并且已经退出了，这种情况在运行一次性任务最为常见.
-
Failed: 此状态表示Pod里至少有一个容器以不正常的状态退出，这个状态出现以为这个你得Debug这个容器的应用，比如查看Pod的Events和日志.
-
Unknown: 这是一个异常状态，表示Pod的状态不能持续的kubelet汇报给kube-apiserver,这很有可能是主从节点(Master和Kubelet)之间的通信出现了问题.
-
细分Pod对象的Status字段
-
Pod对象的Status字段还可以细分一组Conditions,包括: PodScheduled、Ready、Initialized、以及Unschedulable,他们主要用于描述当前Status的具体原因，比如: Pod当前的Status是Pending,对应的Condition是Unschedulable,这表示他的调度出现了问题.
-
投射数据卷Projected Volume
-
是Kubernetes v1.11之后的新特性，在K8s中，有几种特殊的Volume,他们既不是存放容器里的数据，也不是用来和宿主机之间的数据交换，而是为容器提供预先定义好的为新建容器提供字符串的，字符串有长有短，就可以使用不同类型的投射数据卷，当然这个工作普通的volumn也可以实现，但是普通的volumn很容易暴露密码，token或者秘钥等敏感数据,而使用投射数据卷方式可以把敏感数据的资源直接存放在k8s集群的数据库中，可以更方便的控制这些数据，并减少暴露的风险，从容器的角度来看，这些Volume里的信息仿佛是被k8s"投射"(Project)进入容器当中的.
k8s支持的Projected Volume
# Secret: 设置密码可以使用
# ConfigMap: 准备配置文件使用
# Downward API: 设置环境变量
# ServiceAccountToken: 属于一种特殊的Secret,做认证使用.
# 使用时分两步:
# 做出相应的投射数据卷存放到数据库
# 创建容器时使用.
Pod的重启策略
三种重启策略
Always: # 当容器停止，总是重建容器，默认策略
OnFailure: # 当容器异常退出(退出状态码非0）时，才重启容器
Never: # 当容器终止退出，从不重启容器.
Example
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
restartPolicy: OnFailure