1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

K8S架构细分：
1、Master节点（默认不参加实际工作）：

Kubectl：客户端命令行工具，作为整个K8s集群的操作入口；
Api Server：在K8s架构中承担的是“桥梁”的角色，作为资源操作的唯一入口，它提供了认证、授权、访问控制、API注册和发现等机制。客户端与k8s群集及K8s内部组件的通信，都要通过Api Server这个组件；
Controller-manager：负责维护群集的状态，比如故障检测、自动扩展、滚动更新等；
Scheduler：负责资源的调度，按照预定的调度策略将pod调度到相应的node节点上；
Etcd：担任数据中心的角色，保存了整个群集的状态；
2、Node节点：
Kubelet：负责维护容器的生命周期，同时也负责Volume和网络的管理，一般运行在所有的节点，是Node节点的代理，当Scheduler确定某个node上运行pod之后，会将pod的具体信息（image，volume）等发送给该节点的kubelet，kubelet根据这些信息创建和运行容器，并向master返回运行状态。（自动修复功能：如果某个节点中的容器宕机，它会尝试重启该容器，若重启无效，则会将该pod杀死，然后重新创建一个容器）；
Kube-proxy：Service在逻辑上代表了后端的多个pod。负责为Service提供cluster内部的服务发现和负载均衡（外界通过Service访问pod提供的服务时，Service接收到的请求后就是通过kube-proxy来转发到pod上的）；
container-runtime：是负责管理运行容器的软件，比如docker
Pod：是k8s集群里面最小的单位。每个pod里边可以运行一个或多个container（容器），如果一个pod中有两个container，那么container的USR（用户）、MNT（挂载点）、PID（进程号）是相互隔离的，UTS（主机名和域名）、IPC（消息队列）、NET（网络栈）是相互共享的。我比较喜欢把pod来当做豌豆夹，而豌豆就是pod中的container；

1
2
3
4
5
6

每种探测方法能支持以下几个相同的检查参数，用于设置控制检查时间：

initialDelaySeconds：初始第一次探测间隔，用于应用启动的时间，防止应用还没启动而健康检查失败
periodSeconds：检查间隔，多久执行probe检查，默认为10s；
timeoutSeconds：检查超时时长，探测应用timeout后为失败；
successThreshold：成功探测阈值，表示探测多少次为健康正常，默认探测1次。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

spec:
  containers:
    - name: liveness
      image: k8s.gcr.io/busybox
      args:
        - /bin/sh
        - -c
        - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
      livenessProbe: #选择livenessProbe的探测机制
        exec: #执行以下命令
          command:
            - cat
            - /tmp/healthy
        initialDelaySeconds: 5 #在容器运行五秒后开始探测
        periodSeconds: 5 #每次探测的时间间隔为5秒

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    livenessProbe:              #采用livenessProbe机制探测
      httpGet:                  #采用httpget的方式
    scheme:HTTP         #指定协议，也支持https
        path: /healthz          #检测是否可以访问到网页根目录下的healthz网页文件
        port: 8080              #监听端口是8080
      initialDelaySeconds: 3     #容器运行3秒后开始探测
      periodSeconds: 3                #探测频率为3秒

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
- containerPort: 8080
#这里两种探测机制都用上了，都是为了和容器的8080端口建立TCP连接
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

1

[root@master yaml]# kubectl explain deploy.spec.strategy.rollingUpdate

1
2
3
4
5
6

K8s的镜像下载策略有三种：Always、Never、IFNotPresent；

Always：镜像标签为latest时，总是从指定的仓库中获取镜像；
Never：禁止从仓库中下载镜像，也就是说只能使用本地镜像；
IfNotPresent：仅当本地没有对应镜像时，才从目标仓库中下载。
默认的镜像下载策略是：当镜像标签是latest时，默认策略是Always；当镜像标签是自定义时（也就是标签不是latest），那么默认策略是IfNotPresent。

1
2
3

Running：Pod所需的容器已经被成功调度到某个节点，且已经成功运行，
Pending：APIserver创建了pod资源对象，并且已经存入etcd中，但它尚未被调度完成或者仍然处于仓库中下载镜像的过程
Unknown：APIserver无法正常获取到pod对象的状态，通常是其无法与所在工作节点的kubelet通信所致。

1
2
3
4

答：可以通过命令“kubectl explain pod.spec”查看pod的重启策略。（restartPolicy字段）

Always：但凡pod对象终止就重启，此为默认策略。
OnFailure：仅在pod对象出现错误时才重启

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

[root@master httpd-web]# kubectl apply -f httpd2-deploy1.yaml  --record
#运行yaml文件，并记录版本信息；
[root@master httpd-web]# kubectl rollout history deployment httpd-devploy1
#查看该deployment的历史版本
[root@master httpd-web]# kubectl rollout undo deployment httpd-devploy1 --to-revision=1
#执行回滚操作，指定回滚到版本1

#在yaml文件的spec字段中，可以写以下选项（用于限制最多记录多少个历史版本）：
spec:
  revisionHistoryLimit: 5
#这个字段通过 kubectl explain deploy.spec  命令找到revisionHistoryLimit   <integer>行获得

1
2
3
4

在使用基于集合的标签选择器同时指定多个选择器之间的逻辑关系为“与”操作（比如：- {key: name,operator: In,values: [zhangsan,lisi]} ，那么只要拥有这两个值的资源，都会被选中）；
使用空值的标签选择器，意味着每个资源对象都被选中（如：标签选择器的键是“A”，两个资源对象同时拥有A这个键，但是值不一样，这种情况下，如果使用空值的标签选择器，那么将同时选中这两个资源对象）
空的标签选择器（注意不是上面说的空值，而是空的，都没有定义键的名称），将无法选择出任何资源；
在基于集合的选择器中，使用“In”或者“Notin”操作时，其values可以为空，但是如果为空，这个标签选择器，就没有任何意义了。

1
2
3
4
5
6

selector:
  matchLabels: #基于等值
    app: nginx
  matchExpressions: #基于集合
    - { key: name, operator: In, values: [zhangsan, lisi] } #key、operator、values这三个字段是固定的
    - { key: age, operator: Exists, values } #如果指定为exists，那么values的值一定要为空

1
2
3
4
5
6

版本类标签（release）：stable（稳定版）、canary（金丝雀版本，可以将其称之为测试版中的测试版）、beta（测试版）；
环境类标签（environment）：dev（开发）、qa（测试）、production（生产）、op（运维）；
应用类（app）：ui、as、pc、sc；
架构类（tier）：frontend（前端）、backend（后端）、cache（缓存）；
分区标签（partition）：customerA（客户A）、customerB（客户B）；
品控级别（Track）：daily（每天）、weekly（每周）。

1
2
3

[root@master ~]# kubectl get pod --show-labels    #查看pod，并且显示标签内容
[root@master ~]# kubectl get pod -L env,tier      #显示资源对象标签的值
[root@master ~]# kubectl get pod -l env,tier      #只显示符合键值资源对象的pod，而“-L”是显示所有的pod

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

#对pod标签的操作
[root@master ~]# kubectl label pod label-pod abc=123     #给名为label-pod的pod添加标签
[root@master ~]# kubectl label pod label-pod abc=456 --overwrite       #修改名为label-pod的标签
[root@master ~]# kubectl label pod label-pod abc-             #删除名为label-pod的标签
[root@master ~]# kubectl get pod --show-labels

#对node节点的标签操作
[root@master ~]# kubectl label nodes node01 disk=ssd      #给节点node01添加disk标签
[root@master ~]# kubectl label nodes node01 disk=sss –overwrite    #修改节点node01的标签
[root@master ~]# kubectl label nodes node01 disk-         #删除节点node01的disk标签

1
2
3
4

它的一般使用场景如下：

在去做每个节点的日志收集工作；
监控每个节点的的运行状态；

1
2
3
4
5
6

#提高Job执行效率的方法：
spec:
  parallelism: 2           #一次运行2个
  completions: 8           #最多运行8个
  template:
metadata:

1
2
3
4
5

1） 客户端提交Pod的配置信息（可以是yaml文件定义好的信息）到kube-apiserver；
2） Apiserver收到指令后，通知给controller-manager创建一个资源对象；
3） Controller-manager通过api-server将pod的配置信息存储到ETCD数据中心中；
4） Kube-scheduler检测到pod信息会开始调度预选，会先过滤掉不符合Pod资源配置要求的节点，然后开始调度调优，主要是挑选出更适合运行pod的节点，然后将pod的资源配置单发送到node节点上的kubelet组件上。
5） Kubelet根据scheduler发来的资源配置单运行pod，运行成功后，将pod的运行信息返回给scheduler，scheduler将返回的pod运行状况的信息存储到etcd数据中心。

1
2
3
4
5

关闭流程如下：
1、 pod从service的endpoint列表中被移除；
2、 如果该pod定义了一个停止前的钩子，其会在pod内部被调用，停止钩子一般定义了如何优雅的结束进程；
3、 进程被发送TERM信号（kill -14）
4、 当超过优雅退出的时间后，Pod中的所有进程都会被发送SIGKILL信号（kill -9）。

1
2
3
4
5
6

主要使用场景：
1） 只需要临时将数据保存在磁盘上，比如在合并/排序算法中；
2） 作为两个容器的共享存储，使得第一个内容管理的容器可以将生成的数据存入其中，同时由同一个webserver容器对外提供这些页面。
emptyDir的特性：
同个pod里面的不同容器，共享同一个持久化目录，当pod节点删除时，volume的数据也会被删除。如果仅仅是容器被销毁，pod还在，则不会影响volume中的数据。
总结来说：emptyDir的数据持久化的生命周期和使用的pod一致。一般是作为临时存储使用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

在一个PV的yaml文件中，可以对其配置PV的大小，
指定PV的访问模式：

ReadWriteOnce：只能以读写的方式挂载到单个节点；
ReadOnlyMany：能以只读的方式挂载到多个节点；
ReadWriteMany：能以读写的方式挂载到多个节点。，
以及指定pv的回收策略：
recycle：清除PV的数据，然后自动回收；
Retain：需要手动回收；
delete：删除云存储资源，云存储专用；
#PS：这里的回收策略指的是在PV被删除后，在这个PV下所存储的源文件是否删除）。