1 应用周期管理

1.1 资源对象

1.1.1 基础知识

学习目标

这一节，我们从 创建流程、YAML解读、小结 三个方面来学习。

创建流程

为什么kubernetes学习很难？

	k8s对于初学者相当的不友好，主要在于资源对象的学习。而资源对象是：
		- 大量手工的docker容器操作，转换成 各种资源对象
		- k8s操作不同的资源对象，实现容器的自动化操作

资源对象创建流程

那么在Kubernetes集群中，这些资源对象是如何产生的呢？
首先：根据业务应用架构的分析，确定我们要使用的资源对象(Kubernetes中的)
其次：使用描述性语言，编写资源对象的定义文件
再次：基于资源对象定义文件进行对象初始化，形成资源对象。

也就是说，在kubernetes中，资源对象有两种形态：
	文件形态 - 编写出来的资源对象文件，有大量属性组成。
	对象形态 - 基于资源对象文件初始化后出来的应用对象。

资源对象的初始方式

资源对象初始化的方法主要有两大类：
	命令行工具(kubectl)
		- 通过纯粹的 "k8s命令及其选项" 来实现资源的创建
	文件方式(API)
		- 基于 "k8s命令 + 配置文件" 来实现资源的创建
		- 基于 "声明式的配置文件 + kubectl" 来实现资源的创建

生产中如何使用k8s操作业务环境？

生产中如何使用k8s操作业务环境？
	1 保证容器应用是正常运行的
	2 创建专属的资源对象文件
	3 基于资源对象文件创建业务环境
	4 测试业务环境，如果不满足则进行后续动作，否则不做任何改变
		- 调整容器的镜像文件
		- 重新调整资源对象文件
		- 基于新资源对象文件创建并测试新的环境

示例：如何应用资源对象？
	1 梳理需要的资源对象 
		- 容器怎么运行，需要什么操作
		- 对标k8s的资源对象
			
		示例：部署l n m p
			1 部署：deployment
			2 访问：services
			3 配置：configmap
			4 存储：pv+pvc
	2 资源对象准备
		方法1：基于 资源对象文件 【资源清单文件】 yaml
		方法2：命令
			
	3 资源对象创建 
		基于命令 或者 资源对象文件 初始化为 资源对象

YAML解读

定义资源对象文件

	资源定义文件存在的目的：就是用来初始化kubernetes资源对象的。根据其编写语言的种类，资源对象文件的辨析方法一般分为两种：YAML和json，对于部分研发人员来说，他们用json。

	在具体的工作中，大部分的人采用的文件格式是YAML，主要是因为这种格式使用的范围很广。

YAML示例

张氏家族：
  户主：
    姓名: 张三
    性别: 男
    学校:
      - "小学"
      - "中学"
      - "大学"
    家属:
      - 诸葛钢铁
  当家子：
    姓名: 诸葛钢铁
    性别: 女
    ...

1 大小写敏感
2 使用缩进表示层级关系
	- 缩进时不允许使用Tab键，只允许使用空格。
	- 缩进的空格数目不重要，只要相同层级的元素左侧对齐即可
	- 一般情况下，使用2个空格代表属性的层级
3 # 表示单行注释

数据格式

字典样式：其实就是一个键值对，键和值中间使用"冒号+空格"隔开。
    格式：键: 值
    示例：
       app: mysql
       metadata:
         name: mysql

列表样式：这也是一种键值对，只不过它的值是一个列表形式。
    特点：
        1、键和冒号为一行，值为下一行
        2、键和值有层级关系，使用两个空格表示层级关系
        3、列表多元素之间是同级关系，使用 - 表示
	格式：
        键:
          - 值a1
          - 值b1
            值b2
          ...	
    示例：
        args:
         - sleep
         - "1000"
         - message

	基本上，无论你想要什么样的文件结构，你都可以通过Maps和Lists去组合实现。如果我们不确定yaml文件的语法是否正确，我们可以到http://www.yamllint.com/网站上检测一下。

小结

1.1.2 资源属性

学习目标

这一节，我们从 基础知识、简单实践、小结 三个方面来学习。

基础知识

简介

	在Kubernetes中，资源对象的定义文件主要有五部分组成：apiVersion、kind、metadata、spec、status。在这5个中，其中status部分是只能看的，所以我们在定义某个具体资源对象的时候，我们重点关注如下部分内容：

[root@kubernetes-master1 ~]# kubectl get svc kubernetes -o yaml | grep ^[a-Z]
apiVersion: v1			# 资源api的url版本,格式：/apis/$GROUP_NAME/$VERSION
kind: Service			# 资源对象类型，
metadata:				# 资源的元数据信息，资源的名称、标签、注释等信息
spec:					# 资源对象的期望状态值，通过各种属性进行定制
status:					# 资源对象的实际状态值，具体的状态数据，不能设定

k8s资源定义文件,有时候也被称为资源清单，示例如下

yaml格式的pod定义文件完整内容：
apiVersion: v1       	#必选，版本号，例如v1
kind: Pod       		#必选，Pod
metadata:       		#必选，元数据
  name: string       		#必选，Pod名称
  namespace: string    		#Pod所属的命名空间
  labels:      				#自定义标签
    - name: string     			#自定义标签名字
  annotations:       		#自定义注释列表
    - name: string
spec:         			#必选，Pod中容器的详细定义
  containers:      			#必选，Pod中容器列表
  - name: string     			#必选，容器名称
    image: string    			#必选，容器的镜像名称
    imagePullPolicy: [Always | Never | IfNotPresent] 
	# 获取镜像的策略，Alawys-永远要新的，IfnotPresent-笨笨没有则下载镜像，Nerver-仅用本地镜像
    command: [string]    		# 容器的启动命令列表
    args: [string]     			# 容器的启动命令参数列表
    workingDir: string     		# 容器的工作目录
    volumeMounts:    			# 挂载到容器内部的存储卷配置
    - name: string     				# 引用pod定义的共享存储卷的名称
      mountPath: string    			# 存储卷在容器内mount的绝对路径
      readOnly: boolean    			# 是否为只读模式
    ports:       				# 需要暴露的端口库号列表
    - name: string     				# 端口号名称
      containerPort: int   			# 容器需要监听的端口号
      hostPort: int    				# 容器所在主机需要监听的端口号，默认与Container相同
      protocol: string     			# 端口协议，支持TCP和UDP，默认TCP
    env:       					# 容器运行前需设置的环境变量列表
    - name: string     				# 环境变量名称
      value: string    				# 环境变量的值
    resources:       			# 资源限制和请求的设置
      limits:      					# 资源限制的设置
        cpu: string    					# Cpu的限制，单位为core数
        memory: string     				# 内存限制，单位可以为Mib/Gib
      requests:      				# 资源请求的设置
        cpu: string    					# Cpu请求，容器启动的初始可用数量
        memory: string     				# 内存清楚，容器启动的初始可用数量
    livenessProbe:     			# 健康检查的设置，支持exec、httpGet和tcpSocket方式
      exec:      					# 对Pod容器内检查方式设置为exec方式
        command: [string]  				# 指定的命令或脚本
      httpGet:       				# 对Pod内个容器健康检查方法设置为HttpGet
        path: string
        port: number
        host: string
        scheme: string
        HttpHeaders:
        - name: string
          value: string
      tcpSocket:     				# 对Pod内个容器健康检查方式设置为tcpSocket方式
         port: number
       initialDelaySeconds: 0  			# 容器启动完成后首次探测的时间，单位为秒
       timeoutSeconds: 0   				# 探测等待响应的超时时间，单位秒，默认1秒
       periodSeconds: 0    				# 定期探测时间设置，单位秒，默认10秒
       successThreshold: 0
       failureThreshold: 0
       securityContext:
         privileged:false
    restartPolicy: [Always | Never | OnFailure] 
		# Pod的重启策略，Always表示永远重启，OnFailure表示失败时重启，Nerver表示不重启
    nodeSelector: obeject  			# 设置Pod调度到指定label的node上
    imagePullSecrets:    			# Pull镜像时使用的secret名称
    - name: string
    hostNetwork:false      			# 是否使用主机网络模式，默认false
    volumes:       					# 在该pod上定义共享存储卷列表
    - name: string     					# 共享存储卷名称 （volumes类型有很多种）
      emptyDir: {}     					# 临时存储卷
      hostPath: string     				# 挂载Pod所在宿主机的目录
      secret:      						# 挂载秘钥信息到容器中
        scretname: string  
        items:     
        - key: string
          path: string
      configMap:     					# 挂载配置文件
        name: string
        items:
        - key: string
          path: string

资源对象属性查看

	每个部分内部都有大量的键值对表示的资源属性，这些资源对象属性可以使用kubectl explain查看，资源属性的内容非常多，我们可以基于k8s的专用查看命令来学习
	命令格式：kubectl explain <object_name>.[属性.子属性.子子属性....]

命令示例：
~]# kubectl explain pods
KIND:     Pod
VERSION:  v1

DESCRIPTION:
     Pod is a collection of containers that can run on a host. This resource is
     created by clients and scheduled onto hosts.

FIELDS:
   apiVersion   <string>		字符串格式
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#resources

   kind <string>
     ...
   metadata     <Object>		一个对象，表明存在下层子属性
     ...
   spec <Object>
     ...
   status       <Object>
     ...

自己编写资源定义文件有些繁琐，而默认输出的内容又太多，怎么便捷的创建资源文件呢
	kubectl get 资源类型 资源名称 -o yaml --export > deploy-nginx.yaml
命令解析
    -o yaml  	以yaml的格式显示当前资源的所有属性信息。
    --export 	在导出信息的时候，会忽略掉有系统生成的信息,这个功能在1.19版本之后被移除了

简单实践

资源属性实践1-ns资源

创建资源对象专属目录
[root@kubernetes-master1 ~]# mkdir /data/kubernetes/resource -p

查看现有资源对象属性
[root@kubernetes-master1 ~]# kubectl get ns default -o yaml
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: "2062-07-16T02:09:00Z"
  labels:
    kubernetes.io/metadata.name: default
  name: default
  resourceVersion: "202"
  uid: a69decb5-9251-4cf3-b5b4-4787e75fdf06
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

资源属性快捷保存
[root@kubernetes-master1 ~]# cd /data/kubernetes/resource

定制资源属性文件
[root@kubernetes-master1 /data/kubernetes/resource]# kubectl get ns default -o yaml > default.yaml
[root@kubernetes-master1 /data/kubernetes/resource]# cat default.yaml
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: "2062-07-16T02:09:00Z"
  labels:
    kubernetes.io/metadata.name: default
  name: default
  resourceVersion: "202"
  uid: a69decb5-9251-4cf3-b5b4-4787e75fdf06
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

修改资源清单属性文件 -- 修改方法就是，仅留下最核心的即可，一切和时间有关的都丢弃
[root@kubernetes-master1 /data/kubernetes/resource]# cat default.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: default-1
  
应用资源清单文件
[root@kubernetes-master1 /data/kubernetes/resource]# kubectl apply -f default.yaml
namespace/default-1 created
[root@kubernetes-master1 /data/kubernetes/resource]# kubectl  get ns default-1
NAME        STATUS   AGE
default-1   Active   6s

资源属性实践2-pod资源

快速生成pod资源对象文件
[root@kubernetes-master1 /data/kubernetes/resource]# kubectl  get pod superopsmsb-django-web-5bbcb646df-xm8jf -o yaml > myppod.yaml

修改pod资源对象文件
[root@kubernetes-master1 /data/kubernetes/resource]# cat myppod.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: django
  name: django-web
  namespace: default-1
spec:
  containers:
  - image: kubernetes-register.superopsmsb.com/superopsmsb/django_web:v0.1
    name: django
    
应用资源清单文件
[root@kubernetes-master1 /data/kubernetes/resource]# kubectl  apply -f myppod.yaml
pod/django-web created

到指定的命名空间中查看资源对象
[root@kubernetes-master1 /data/kubernetes/resource]# kubectl  get pod -n default-1
NAME         READY   STATUS    RESTARTS   AGE
django-web   1/1     Running   0          6s
结果显示：
	在指定的default-1命名空间中，获取了对应资源。

小结

1.2 Pod基础

1.2.1 Pod概述

学习目标

这一节，我们从 资源对象解读、应用解析、小结 三个方面来学习。

资源对象解读

官方简介

	Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.

	It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon 15 years of experience of running production workloads at Google, combined with best-of-breed ideas and practices from the community.

	在Kubernetes的官方简介中，Kubernetes是通过组合容器将应用放置到一个个的逻辑单元中，达到快速管理业务应用的效果，这个逻辑单元就是Pod。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Amvnua4i-1688393635932)(image/image-20210916144202301.png)]

注意：
	存储卷隶属于 pod，而非容器，它是通过挂载方式被容器使用的。

交付单元

传统主机阶段 - 以单台主机或者应用软件的方式交付项目
容器环境阶段 - 单个容器的方式部署整个项目功能，然后交付出去
任务编排阶段 - 以Pod(容器集合)方式，统一管理相关联的容器应用

应用解析

基本属性

Pod vs 容器
	每个Pod都是应用的一个(子应用)实例，有专用的ip。
	一个Pod可以有多个容器，借助于pause容器彼此间共享网络和存储资源。
	不同业务的容器分别放在不同的pod中。
	
Pod vs Pod
	同一Pod中的容器总会被调度到相同Node节点
	Pod分为普通的Pod和静态Pod(一般不用)

应用 vs 应用
	每个service的enpoint地址由coredns组件解析为对应的服务名称，<br>其他service的pod通过访问该 名称 达到应用间通信的效果
	
应用 vs pod
	应用彼此间通过service实现数据的流转。
	service本质上是集群内部的iptables规则。

数据通信

Pod内 多容器通信
	- 容器间通信(容器模型)
单节点内多Pod通信
	- 主机间容器通信(host模型)
多节点内多Pod通信
	- 跨主机网络解决方案(overlay模型)，比如我们做的flannel

资源管理

k8s集群通过pod实现了大量业务应用容器的统一管理，而k8s也提供了大量的资源对象来对 pod进行管理：
	通过控制器来确保 pod的运行和数量 符合用户的期望状态
	通过网络资源来确保 pod的应用服务 可以被外部的服务来进行访问

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bSQ2V4yF-1688393635934)(image/image-20210916154550431.png)]

小结

1.2.2 简单实践

学习目标

这一节，我们从 资源创建、资源操作、小结 三个方面来学习。

资源创建

简介

	关于kubernetes资源的创建都有两种方式：命令行方法和配置文件方法。我们这里就以pod资源对象为例，来创建一下。

命令行创建Pod对象:

语法：
	kubectl run NAME --image=image [--port=port] [--replicas=replicas] 
参数详解
    --dry-run=true		以模拟的方式来进行执行命令
    --env=[]			执行的时候，向对象中传入一些变量
    --image=''			指定容器要运行的镜像
    --labels=''			设定pod对象的标签
    --limits='cpu=500m,memory=512Mi'	设定容器启动后的资源配置
    --port=''			设定容器暴露的端口

创建资源对象
[root@kubernetes-master1 /data/kubernetes/resource]# kubectl run nginx-test --image=kubernetes-register.superopsmsb.com/superopsmsb/nginx
pod/nginx-test created

查看资源对象
[root@kubernetes-master1 /data/kubernetes/resource]# kubectl get pod
NAME         READY   STATUS    RESTARTS   AGE
nginx-test   1/1     Running   0          4s

资源清单方式创建一个Pod：

定制资源清单文件
apiVersion: v1
kind: Pod
metadata:
  name: superopsmsb-nginx
spec:
  containers:
  - name: nginx
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx
注意：
	资源定义文件中可以同时写多个资源对象，彼此间使用"---"隔开就可以了
	
应用资源清单文件
    kubectl create|apply -f resource_file.yaml
    子命令解析：
   		create 仅仅是创建一个对象，若对象已存在，则不会重复创建
    	apply  比较前后配置差异，有差异则使用

创建资源对象目录
[root@kubernetes-master1 ~]# mkdir /data/kubernetes/pod -p
[root@kubernetes-master1 ~]# cd /data/kubernetes/pod

创建资源对象文件
[root@kubernetes-master1 /data/kubernetes/pod]# vim 01_kubernetes_pod_run.yaml
	内容与上面参考文件一致

应用资源对象文件
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 01_kubernetes_pod_run.yaml
pod/superopsmsb-nginx created

查看资源对象
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl get pod superopsmsb-nginx
NAME                READY   STATUS    RESTARTS   AGE
superopsmsb-nginx   1/1     Running   0          12s

资源操作

信息查看

	所谓的信息查看，其实就是资源对象相关属性信息的查看方法，我们这里统一的查看一下：
		应用运行日志查看 logs
		资源创建信息查看 describe
		资源运行属性查看 get
		资源创建属性查看 explain

查看容器运行日志
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl logs superopsmsb-nginx
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/

查看资源的信息
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl describe pod superopsmsb-nginx
Name:         superopsmsb-nginx
Namespace:    default
...

查看资源运行信息
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  get pod
NAME                READY   STATUS    RESTARTS   AGE
superopsmsb-nginx   1/1     Running   0          19m
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  get pod -o wide
NAME                READY   STATUS    RESTARTS   AGE   IP            NODE               NOMINATED NODE   READINESS GATES
superopsmsb-nginx   1/1     Running   0          19m   10.244.5.15   kubernetes-node2   <none>           <none>

查看资源创建属性信息
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  explain pod
KIND:     Pod
VERSION:  v1

pod内部信息

pod内部必须有一个pause容器，而且管理所有的应用容器
[root@kubernetes-node3 ~]# docker ps | awk '{print $1,$2,$3}'
CONTAINER ID IMAGE
eecacd0ad30f 61825a6dffbf "/bin/bash
4db99cee1f13 kubernetes-register.superopsmsb.com/google_containers/pause:3.6 "/pause"
aad1e756c686 kubernetes-register.superopsmsb.com/google_containers/dashboard "/dashboard
a43fb20fbb41 kubernetes-register.superopsmsb.com/google_containers/pause:3.6 "/pause"
606021a6c2a8 e237e8506509 "/opt/bin/flanneld
f18ecb5778f4 db4da8720bcb "/usr/local/bin/kube…"
6f595823d7c9 kubernetes-register.superopsmsb.com/google_containers/pause:3.6 "/pause"
206d037ee9e4 kubernetes-register.superopsmsb.com/google_containers/pause:3.6 "/pause"
[root@kubernetes-node3 ~]# docker ps | grep Up | wc -l
8
[root@kubernetes-node3 ~]# docker ps | grep pause | wc -l
4

pod内部资源的属性结构
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl describe pod superopsmsb-nginx
-----------基本的描述信息
Name:         superopsmsb-nginx
Namespace:    default
...
---容器信息
Containers:
---资源对象运行条件
Conditions:
---资源对象的数据信息
Volumes:
---资源对象的其他信息
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:   
---资源对象创建过程信息
Events:

其他操作

	所谓的其他操作，其实就是资源对象的编辑、更改、删除操作方法
		资源对象编辑操作 edit
		资源对象删除操作 delete

资源对象查看标签操作
[root@kubernetes-master1 ~]# kubectl get pod nginx-test --show-labels
NAME         READY   STATUS    RESTARTS   AGE   LABELS
nginx-test   1/1     Running   0          52m   run=nginx-test

修改资源对象属性
[root@kubernetes-master1 ~]# kubectl edit pod nginx-test
...
metadata:
  labels:
    run: nginx-test
    run: nginx-test2    # 以增加的方式更改
    ...

查看效果
[root@kubernetes-master1 ~]# kubectl edit pod nginx-test
pod/nginx-test edited
[root@kubernetes-master1 ~]# kubectl get pod nginx-test --show-labels
NAME         READY   STATUS    RESTARTS   AGE   LABELS
nginx-test   1/1     Running   0          54m   run=nginx-test2

资源对象查看标签操作
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl get pod -n default-1
NAME         READY   STATUS    RESTARTS   AGE
django-web   1/1     Running   0          9h
资源对象删除操作
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  delete pod django-web -n default-1
pod "django-web" deleted
查看效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl get pod -n default-1
No resources found in default-1 namespace.

清理default命名空间资源
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  delete pod nginx-test superopsmsb-nginx
pod "nginx-test" deleted
pod "superopsmsb-nginx" deleted

小结

1.2.3 流程解读

学习目标

这一节，我们从 创建流程、周期解读、小结 三个方面来学习。

创建流程

流程示意图

流程解析

1 用户通过多种方式向master结点上的API-Server发起创建一个Pod的请求
2 apiserver 将资源对象操作信息写入 etcd
3 scheduluer 检测到api-Server上有建立Pod请求，开始调度该Pod到指定的Node
	同时借助于apiserver更新信息到etcd
4 kubelet 检测到有新的 Pod 调度过来，通过容器引擎(不限于Docker)创建并运行该 Pod对象
5 kubelet 通过 container runtime 取到 Pod 状态，并同步信息到 apiserver，由它更新信息到etcd

周期解读
简介

	Kubernetes是以pod的形式对所有应用服务容器进行管理的，每一个应用服务对应一个Pod，所以与业务应用对象一样，Pod也有独立的生命周期。

顺序1：init容器
    初始化容器，独立于主容器之外，pod可以拥有任意数量的init容器，所有init顺序执行完成后，才启动主容器。它主要是为了为主容器准备应用的功能，比如向主容器的存储卷写入数据，然后将存储卷挂载到主容器上。

顺序2：生命周期钩子
    启动后钩子
    	PostStart - 主程序启动后执行的程序
    运行中钩子
    	Liveiness - 判断当前容器是否处于存活状态
    	Readiness - 判断当前容器是否可以正常的对外提供服务
    停止前钩子
    	PreStop - 主程序关闭前执行的程序。

顺序3：pod关闭
    当API服务器接收到删除pod对象的命令后，移除资源对象。

小结

1.2.4 应用解析

学习目标

这一节，我们从 状态解析、配置解读、小结 三个方面来学习。

状态解析

多容器模式

在pod内部运行多个应用容器同时存在(不包含pause容器)，这些容器存在包括多种形式：
	sideCar模式   - 为主容器提供辅助功能
	Adapater模式  - 帮助主容器通信过程中的信息格式修正
	Ambassador模式 - 利用pod内多容器共享数据的特性，代理后端容器和外部的其他应用进行交流

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c3AraGq1-1688393635935)(image/image-20220717082017491.png)]

Pod状态

正常情况：
    在Kubernetes集群中，真正工作的是Node节点，所以业务的子应用也就是Pod，肯定会被分配到相应的Node节点上。Pod一旦绑定到Node节点，就永远不会移动，即便Node节点发生重启。
    Pod作为一种资源对象，在整个业务生命周期中，会随着操作而出现五种状态：
    	pending，running，succeeded，failed，Unknown

异常情况：
    业务运行过程中不可避免会出现意外，这个时候有三种策略对Pod进行管理：
    OnFailure，Never和Always（默认）
    
参考资料：
	https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

容器状态

	容器作为Pod统一管理的对象，所以在pod的运行过程中，容器在pod的生命周期中也有对应的状态，这些状态主要有几种分类：
    Waiting 容器处于 Running 和Terminated 状态之前的状态
    Running 容器能够正常的运行状态，容器正常了，pod提供的服务才可以对外开放
    Terminated 容器已经被成功的关闭了
    
注意：
	这些容器状态对于pod是否真正向外提供服务访问非常重要。

镜像拉取状态

Always pod每次创建容器，都是从远程仓库拉取新镜像，这是默认值
IfNotPresent 如果Node所在节点的本地仓库不存在的话，再拉取新镜像
Never不获取新镜像,仅用本地镜像来运行容器
注意：
	这三种状态的不同使用，在基于kubernetes的持续交付过程中，有着非常重要的作用。

简单实践

查看pod的生命周期

生命周期属于pod的运行状态中的属性
[root@kubernetes-master1 ~]# kubectl explain pods.status.phase
KIND:     Pod
VERSION:  v1

FIELD:    phase <string>

DESCRIPTION:
     The phase of a Pod is a simple, high-level summary of where the Pod is in
     its lifecycle. The conditions array, the reason and message fields, and the
     individual container status arrays contain more detail about the pod's
     status. There are five possible phase values:

     Pending: The pod has been accepted by the Kubernetes system, but one or
     more of the container images has not been created. This includes time
     before being scheduled as well as time spent downloading images over the
     network, which could take a while. Running: The pod has been bound to a
     node, and all of the containers have been created. At least one container
     is still running, or is in the process of starting or restarting.
     Succeeded: All containers in the pod have terminated in success, and will
     not be restarted. Failed: All containers in the pod have terminated, and at
     least one container has terminated in failure. The container either exited
     with non-zero status or was terminated by the system. Unknown: For some
     reason the state of the pod could not be obtained, typically due to an
     error in communicating with the host of the pod.

     More info:
     https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-phase

查看容器的状态

容器状态属于pod状态中的子项
[root@kubernetes-master1 ~]# kubectl explain pods.status.containerStatuses.state
KIND:     Pod
VERSION:  v1

RESOURCE: state <Object>

DESCRIPTION:
     Details about the container's current condition.

     ContainerState holds a possible state of container. Only one of its members
     may be specified. If none of them is specified, the default one is
     ContainerStateWaiting.

FIELDS:
   running      <Object>
     Details about a running container

   terminated   <Object>
     Details about a terminated container

   waiting      <Object>
     Details about a waiting container

查看镜像的获取策略

镜像的获取策略是pod创建时候用到的，所以在spec的期望属性中
[root@kubernetes-master1 ~]# kubectl explain pod.spec.containers.imagePullPolicy
KIND:     Pod
VERSION:  v1

FIELD:    imagePullPolicy <string>

DESCRIPTION:
     Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always
     if :latest tag is specified, or IfNotPresent otherwise. Cannot be updated.
     More info:
     https://kubernetes.io/docs/concepts/containers/images#updating-images

小结

1.2.5 初始化容器

学习目标

这一节，我们从 基础知识、简单实践、小结 三个方面来学习。

基础知识

简介

	主容器启动之前要运行的容器，常用于执行一些预置操作，初始化容器必须运行完成至结束，每个初始化容器都必须按定义顺序串行运行
	更多参考信息：https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

属性信息查看：
	kubectl explain pods.spec.initContainers

简单实践

准备基准测试镜像

为了不影响后续的资源操作，我们获取远程镜像到本地，然后推送到镜像仓库
[root@kubernetes-master1 ~]# docker pull busybox:1.28
[root@kubernetes-master1 ~]# docker tag busybox:1.28 kubernetes-register.superopsmsb.com/superopsmsb/busybox:1.28
[root@kubernetes-master1 ~]# docker push kubernetes-register.superopsmsb.com/superopsmsb/busybox:1.28
    [root@kubernetes-master1 ~]# docker rmi busybox:1.28

初始化容器的实践

查看初始化容器资源清单文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 02_kubernetes_pod_init.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-init-test
  labels:
    app: superopsmsb
spec:
  containers:
  - name: myapp-container
    image: kubernetes-register.superopsmsb.com/superopsmsb/busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: kubernetes-register.superopsmsb.com/superopsmsb/busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]

应用资源清单文件
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 02_kubernetes_pod_init.yaml
pod/pod-init-test created

检查效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  get pod
NAME            READY   STATUS     RESTARTS   AGE
pod-init-test   0/1     Init:0/1   0          4s

[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  logs pod-init-test -c init-myservice
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

nslookup: can't resolve 'myservice.default.svc.cluster.local'
waiting for myservice
...

[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  describe pod pod-init-test
Name:         pod-init-test
... 
Init Containers:
  init-myservice:
    ...
    State:          Running
      Started:      Sun, 17 Jul 2022 08:57:43 +0800
    Ready:          False
    ...
Containers:
  myapp-container:
    ...
    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    ...

定制依赖的service文件

查看初始化容器资源清单文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 03_kubernetes_pod_init_svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

应用资源清单文件
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 03_kubernetes_pod_init_svc.yaml
service/myservice created

查看资源对象
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  get svc myservice
NAME        TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
myservice   ClusterIP   10.105.54.139   <none>        80/TCP    4s

查看初始化容器效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  get pod pod-init-test
NAME            READY   STATUS    RESTARTS   AGE
pod-init-test   1/1     Running   0          4m45s

[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  logs pod-init-test -c init-myservice | tail -n5
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      myservice.default.svc.cluster.local
Address 1: 10.105.54.139 myservice.default.svc.cluster.local

清理环境
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  delete -f 02_kubernetes_pod_init.yaml -f 03_kubernetes_pod_init_svc.yaml

小结

1.2.6 Sidecar实践

学习目标

这一节，我们从 基础知识、简单实践、小结 三个方面来学习。

基础知识

简介

	所谓的多容器，其实指的是pod内部允许出现多个容器的操作，sidecar就属于多容器的一种表现方式。

为什么存在多容器？

	POD中的多个容器运行在同一个node上，它们同一个namespace的所有资源，还包括使用共享数据卷，同时采用本地通信方式能够高效通信，此外，POD可以以单元的模式来管理紧耦合的多个应用程序容器。

注意：
	由于容器设计的思想就是 -- 一个容器一个应用，如果一个容器多个应用的话，不仅仅容量无限大，而且导致应用排错想当困难，程序后续解耦艰难。

sidecar简介

	在一个pod内启动两个容器，访问B容器的时候，都需要经过A容器，只有通过A处理后的数据才会发送给B容器。在整个过程中，A容器就是B容器应用的代理服务器。
	典型场景：使用 sidecar 容器运行日志代理
		sidecar容器将应用程序日志传送到自己的标准输出。
		sidecar容器运行一个日志代理，配置该日志代理以便从应用容器收集日志。

属性解析

资源属性：
[root@kubernetes-master1 ~]# kubectl explain pod.spec.containers
KIND:     Pod
VERSION:  v1

RESOURCE: containers <[]Object>

DESCRIPTION:
     List of containers belonging to the pod. Containers cannot currently be
     added or removed. There must be at least one container in a Pod. Cannot be
     updated.

     A single application container that you want to run within a pod.
     
属性解读：
	这里我们可以看到 Containers属性是一个 [] 对象 -- 也就是说可以包含多个容器的配置。

简单实践

查看初始化容器资源清单文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 04_kubernetes_pod_sidecar.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sidecar-test
spec:
  containers:
  - name: nginx-web
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    volumeMounts:
    - name: nginx-index
      mountPath: /usr/share/nginx/html
  - name: change-index
    image: kubernetes-register.superopsmsb.com/superopsmsb/busybox:1.28
    # 每过2秒更改一下文件内容
    command: ['sh', '-c', 'for i in $(seq 100); do echo index-$i > /testdir/index.html;sleep 2;done']
    volumeMounts:
    - name: nginx-index
      mountPath: /testdir
  volumes:
  - name: nginx-index
    emptyDir: {}

执行资源清单文件
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl apply -f 04_kubernetes_pod_sidecar.yaml

查看效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  get pod -o wide
NAME           READY   STATUS    RESTARTS   AGE   IP            NODE ...
sidecar-test   2/2     Running   0          3s    10.244.5.21   kubernetes-node2

[root@kubernetes-master1 /data/kubernetes/pod]# curl 10.244.5.21
index-7
[root@kubernetes-master1 /data/kubernetes/pod]# curl 10.244.5.21
index-8
[root@kubernetes-master1 /data/kubernetes/pod]# curl 10.244.5.21
index-9
[root@kubernetes-master1 /data/kubernetes/pod]# curl 10.244.5.21
index-10

清理环境
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  delete -f 04_kubernetes_pod_sidecar.yaml

小结

1.2.7 静态POD实践

学习目标

这一节，我们从 基础知识、简单实践、小结 三个方面来学习。

基础知识

应用场景

    对于pod来说，基于控制的特性主要有两类：静态pod和普通pod。普通pod其实就是我们一直实践中用到的pod，也就是可以直接被集群中的kubelet进行增删改查的pod，静态pod在本质上与动态pod没有区别，只是在于静态pod只能在特定的节点上运行，由特定节点上的kubelet进程来管理，对于集群kubectl来说，只能看，不能乱动。
    静态pod常常用于某些结点上的一些隐私操作或者核心操作，而且这些操作往往受到特定结点的场景约束，比如某些定向监控、特定操作。

属性解析

对于静态pod来说，他主要的实现方式是：配置文件方式。
	所谓的配置文件的方式，其实就是在特定的目录下存放我们定制好的资源对象文件，然后结点上的kubelet服务周期性的检查该目录下的所有内容，对静态pod进行增删改查。其配置方式主要有两步
    1 定制kubelet服务定期检查配置目录
    2 增删定制资源文件

参考资料：
	https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/static-pod/

简单实践

信息查看

软件组成
[root@kubernetes-master1 ~]# rpm -ql kubelet
/etc/kubernetes/manifests
/etc/sysconfig/kubelet
/usr/bin/kubelet
/usr/lib/systemd/system/kubelet.service

服务状态
[root@kubernetes-master1 ~]# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
     Active: active (running)
   ...
结果显示：
	kubelet服务，系统服务文件是kubelet.service，但是在启动服务时候，还加载了kubelet.service.d目录下的10-kubeadm.conf文件的内容

查看加载文件内容
[root@kubernetes-master1 ~]# cat /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf
# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
...
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
...
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
...
结果显示：
	kubelet的配置参数主要是在/var/lib/kubelet/config.yaml文件中定义

kubelet配置参数
[root@kubernetes-master1 ~]# grep static /var/lib/kubelet/config.yaml
staticPodPath: /etc/kubernetes/manifests
结果显示：
	该文件是一个yaml格式的，里面设置了大量的配置参数，其中有一项关键的就是staticPodPath。其实我们还可以直接	在/etc/kubernetes/kubelet.conf文件中使用 --pod-manifest-path=<the directory>的方式指定静态pod的路径。

	到目前为止，根据我们的查看资料，对于kubeadm的环境来说，他默认情况下已经配置好了静态pod的专用目录，就是/etc/kubernetes/manifests，而我们没有看到静态pod的效果，主要是该目录中并没有任何资源对象文件。

master节点查看效果
[root@kubernetes-master1 ~]# ls /etc/kubernetes/manifests/
etcd.yaml  kube-apiserver.yaml  kube-controller-manager.yaml  kube-scheduler.yaml

node点查看效果
[root@kubernetes-node1 ~]# ls /etc/kubernetes/manifests/
[root@kubernetes-node1 ~]#

静态pod实践

master查看集群当前效果
[root@kubernetes-master1 ~]# kubectl  get pod
No resources found in default namespace.

查看特制的静态资源文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 05_kubernetes_pod_static.yaml
apiVersion: v1
kind: Pod
metadata:
  name: superopsmsb-static-pod
spec:
  containers:
    - name: nginx
      image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1

传输到指定的node节点
[root@kubernetes-master1 /data/kubernetes/pod]# scp 05_kubernetes_pod_static.yaml root@10.0.0.16:/etc/kubernetes/manifests/
05_kubernetes_pod_static.yaml                                                    100%  180   148.6KB/s   00:00

master节点查看效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl get pod -o wide
NAME                                      READY   STATUS    RESTARTS   AGE   IP           NODE               NOMINATED NODE   READINESS GATES
superopsmsb-static-pod-kubernetes-node2   1/1     Running   0          12s   10.244.4.7   kubernetes-node2   <none>           <none>
结果显示：
	负载工作节点的静态pod目录，只要配置文件发生变化，立刻都会显示出来

master节点尝试删除静态pod
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  delete pod superopsmsb-static-pod-kubernetes-node2
pod "superopsmsb-static-pod-kubernetes-node2" deleted
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  get pod
NAME                                      READY   STATUS    RESTARTS   AGE
superopsmsb-static-pod-kubernetes-node2   1/1     Running   0          3s
结果显示:
	由于静态pod的增删主要是基于node节点上的kubelet来实现的，所以master无法完全删除。

尝试编辑pod对象
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  set image pod superopsmsb-static-pod-kubernetes-node2 nginx=kubernetes-register.superopsmsb.com/superopsmsb/nginx:1.16.0
pod/superopsmsb-static-pod-kubernetes-node2 image updated
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  get pod -o wide
NAME                                      READY   STATUS    RESTARTS   AGE     IP           NODE               NOMINATED NODE   READINESS GATES
superopsmsb-static-pod-kubernetes-node2   1/1     Running   0          2m27s   10.244.4.7   kubernetes-node2   <none>           <none>
[root@kubernetes-master1 /data/kubernetes/pod]# curl 10.244.4.7
Hello Nginx, superopsmsb-static-pod-kubernetes-node2-1.23.0
结果显示：
	静态pod不受kubectl的编辑管理

移除静态Pod资源
[root@kubernetes-node2 ~]# ls /etc/kubernetes/manifests/
05_kubernetes_pod_static.yaml
[root@kubernetes-node2 ~]# mv /etc/kubernetes/manifests/05_kubernetes_pod_static.yaml  ./
[root@kubernetes-node2 ~]# ls /etc/kubernetes/manifests/
[root@kubernetes-node2 ~]#

回到master结点上，查看效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl get pod -o wide
No resources found in default namespace.
结果显示
	只要静态pod的文件一旦有变动，在集群中立刻都能看到现象

小结

1.3 Pod进阶

1.3.1 Pod探测机制

学习目标

这一节，我们从 探测原理、配置解读、小结 三个方面来学习。

探测原理

简介

	我们需要一种可以及时的获取容器的各种运行状态数据，所以对于容器任务编排的环境下，他们都应该考虑到一种场景：主动的将容器运行的相关数据暴露出来 -- 数据暴露接口。常见的就是 包含大量metric指标数据的API接口。
对于k8s内部的pod环境来说，常见的这些API接口有：
	process health	状态健康检测接口
	metrics			监控指标接口
	readiness		容器可读状态的接口
	liveness		容器存活状态的接口
	tracing			全链路监控的埋点(探针)接口
	logs			容器日志接口

探测属性

LivenessProbe：
	周期性检测，检测未通过时，kubelet会根据restartPolicy的定义来决定是否会重启该容器；未定义时，Kubelet认为只容器未终止，即为健康；
	参考资料：kubectl explain pod.spec.containers.livenessProbe
ReadinessProbe：
	周期性检测，检测未通过时，与该Pod关联的Service，会将该Pod从Service的后端可用端点列表中删除；直接再次就绪，重新添加回来。未定义时，只要容器未终止，即为就绪； 
	注意：ReadinessProbe 检测失败不会重启Pod
	参考资料：kubectl explain pod.spec.containers.ReadnessProbe
StartupProbe：
	实现用户自定义的一些探测机制，效果等同于livenessProbe，区别在于应用不同的参数或阈值； 
	参照资料：kubectl explain pod.spec.containers.startupProbe

官网资料：https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes

配置解读

探针类型

	对于Pod中多容器的场景，只有所有容器就绪，才认为Pod就绪，kubelet定期执行livenessProbe探针来诊断Pod的健康状况，Pod探针的实现方式有很多，常见的有如下三种：
	ExecAction - 直接执行命令，命令成功返回表示探测成功；
	TCPSocketAction - 端口能正常打开，即成功
	HTTPGetAction - 向指定的path发HTTP请求，2xx, 3xx的响应码表示成功

属性解读

spec:
  containers:
  - name: …
    image: …
    livenessProbe:
      exec <Object>     				# 命令式探针
      httpGet <Object>  				# http GET类型的探针
      tcpSocket <Object>  				# tcp Socket类型的探针
      initialDelaySeconds <integer>  	# 发起初次探测请求的延后时长
      periodSeconds <integer>         	# 请求周期
      timeoutSeconds <integer>        	# 超时时长，默认是1。
      successThreshold <integer>      	# 连续成功几次，才表示状态正常，默认值是1
      failureThreshold <integer>      	# 连续失败几次，才表示状态异常，默认值是3
注意：
	这里面仅仅罗列的livenessProbe ，readnessProbe 的属性与livenessProbe一样

状态探测

[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 01_kubernetes_pod_run.yaml
pod/superopsmsb-nginx created
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  get pod
NAME                READY   STATUS    RESTARTS   AGE
superopsmsb-nginx   1/1     Running   0          4s
状态解读：
	1/1 就是 容器服务状态/pod创建状态
		1 就是状态正常，0就是状态异常

flask应用镜像

获取基本的python镜像
docker pull python:3.8
docker tag python:3.8 kubernetes-register.superopsmsb.com/superopsmsb/python:3.8
docker push kubernetes-register.superopsmsb.com/superopsmsb/python:3.8
docker rmi python:3.8

定制专属的flask应用文件
[root@kubernetes-master1 ~]# mkdir -p /data/images/web/flask/code
[root@kubernetes-master1 ~]# cd /data/images/web/flask
[root@kubernetes-master1 /data/images/web/flask]# cat code/flask_app.py
from flask import Flask, request, Response, make_response
import sys,os, socket, time

# 创建应用
app = Flask(__name__)

# 设定访问首页
@app.route('/')
def index():
    return ('Hello Flask-V0.1, 来访者ip: {}, 主机名: {}, Pod地址: {}!\n'.format(request.remote_addr, os.environ.get('HOSTNAME'), socket.gethostbyname(socket.gethostname())))

# 设定基本环境变量
health_status = {'liveness': 'OK', 'readness': 'OK'}
probe_count = {'liveness': 0, 'readness': 0}

# 设定/liveness 状态页面
@app.route('/liveness', methods=['GET','POST'])
def liveness():
    if request.method == 'POST':
        status = request.form['liveness']
        health_status['liveness'] = status
        return ''

    else:
        if probe_count['liveness'] == 0:
            time.sleep(1)
        probe_count['liveness'] += 1
        if health_status['liveness'] == 'OK':
            return make_response(health_status['liveness']+'\n', 200)
        else:
            return make_response(health_status['liveness']+'\n', 506)

# 设定 /readness 状态页面
@app.route('/readness', methods=['GET','POST'])
def readness():
    if request.method == 'POST':
        status = request.form['readness']
        health_status['readness'] = status
        return '\n'

    else:
        if probe_count['readness'] == 0:
            time.sleep(1)
        probe_count['readness'] += 1
        if health_status['readness'] == 'OK':
            return make_response(health_status['readness']+'\n', 200)
        else:
            return make_response(health_status['readness']+'\n', 507)


# 启动程序
def main():
    port = 80
    host = '0.0.0.0'
    debug = False

    app.run(host=str(host), port=int(port), debug=bool(debug))


if __name__ == "__main__":
    main()

定制专属的Dockerfile文件
[root@kubernetes-master1 /data/images/web/flask]# cat Dockerfile
# 构建一个基于flask的定制镜像
# 基础镜像
FROM kubernetes-register.superopsmsb.com/superopsmsb/python:3.8
# 镜像作者
MAINTAINER shuji@superopsmsb.com

# 安装查看
RUN pip install flask
# 添加文件
ADD code/flask_app.py /data/code/flask_app.py

# 暴露端口
EXPOSE 80

# 执行命令
CMD ["python3", "/data/code/flask_app.py"]

测试效果

创建镜像文件
[root@kubernetes-master1 /data/images/web/flask]# docker build -t kubernetes-register.superopsmsb.com/superopsmsb/flask_web:v0.1 .

测试镜像文件
[root@kubernetes-master1 /data/images/web/flask]# docker run -d --name flask_test -p 666:80 kubernetes-register.superopsmsb.com/superopsmsb/flask_web:v0.1
2b526340b5255cc69823450bc9c7d34117ee46b4f634019fc887068d042f362c
[root@kubernetes-master1 /data/images/web/flask]# curl 10.0.0.12:666
Hello Flask-V0.1, 来访者ip: 10.0.0.12, 主机名: 2b526340b525, Pod地址: 172.17.0.2!
[root@kubernetes-master1 /data/images/web/flask]# curl 10.0.0.12:666/liveness
OK
[root@kubernetes-master1 /data/images/web/flask]# curl 10.0.0.12:666/readness
OK

提交镜像文件
[root@kubernetes-master1 /data/images/web/flask]# docker push kubernetes-register.superopsmsb.com/superopsmsb/flask_web:v0.1

小结

1.3.2 命令探测

学习目标

这一节，我们从 配置解读、简单实践、小结 三个方面来学习。

配置解读

场景

	对于pod生命周期中的状态检测也好、还是pod生命周期中的钩子函数也好，其本质上都是借助于不同的方式对于特定资源对象属性信息的一种探测而已，虽然场景不同，但是在命令执行的本质上来说，没有太大的区别，所以接下来的实践，可以是 readnessProbe、livenessProbe、等等场景。

简介

	所谓exec 其实就是我们尝试通过在容器内部来执行一个命令，看看能不能执行成功，如果成功，那么说明该对象是ok的，否则就是失败的。
	exec的执行动作命令，其实就是我们之前借助于kubectl exec 到容器中执行的command一样。

属性解读

查看属性结构
[root@kubernetes-master1 ~]# kubectl  explain pod.spec.containers.livenessProbe.exec
KIND:     Pod
VERSION:  v1

RESOURCE: exec <Object>

DESCRIPTION:
     Exec specifies the action to take.

     ExecAction describes a "run in container" action.

FIELDS:
   command      <[]string>
     Command is the command line to execute inside the container, the working
     directory for the command is root ('/') in the container's filesystem. The
     command is simply exec'd, it is not run inside a shell, so traditional
     shell instructions ('|', etc) won't work. To use a shell, you need to
     explicitly call out to that shell. Exit status of 0 is treated as
     live/healthy and non-zero is unhealthy.

简单实践

官方实践案例

查看资源对象文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 06_kubernetes_pod_exec_check.yaml
apiVersion: v1
kind: Pod
metadata:
  name: superopsmsb-liveness-exec
spec:
  containers:
  - name: liveness-exec
    image: kubernetes-register.superopsmsb.com/superopsmsb/busybox:1.28
    command: ["/bin/sh","-c","touch /tmp/healthy; sleep 3; rm -rf /tmp/healthy;sleep 3600"]
    livenessProbe:
      exec:
        command: ["test", "-e","/tmp/healthy"]
      
创建资源对象
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 06_kubernetes_pod_exec_check.yaml
pod/superopsmsb-liveness-exec created

查看效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl get pod
NAME                        READY   STATUS    RESTARTS   AGE
superopsmsb-liveness-exec   1/1     Running   0          2s

实时监控
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl get pod -w
NAME                        READY   STATUS    RESTARTS   AGE
superopsmsb-liveness-exec   1/1     Running   0          48s
superopsmsb-liveness-exec   1/1     Running   1 (1s ago)   61s
superopsmsb-liveness-exec   1/1     Running   2 (1s ago)   2m1s
superopsmsb-liveness-exec   1/1     Running   3 (1s ago)   3m1s
...

状态描述
[root@kubernetes-master1 ~]# kubectl describe pod superopsmsb-liveness-exec
...
Events:
  Type     Reason     Age                  From               Message
  ----     ------     ----                 ----               -------
  Normal   Scheduled  2m46s                default-scheduler  Successfully assigned default/superopsmsb-liveness-exec to kubernetes-node1
  Normal   Pulling    2m45s                kubelet            Pulling image "kubernetes-register.superopsmsb.com/superopsmsb/busybox:1.28"
  Normal   Pulled     2m45s                kubelet            Successfully pulled image "kubernetes-register.superopsmsb.com/superopsmsb/busybox:1.28" in 247.015632ms
  Normal   Created    46s (x3 over 2m45s)  kubelet            Created container liveness-exec
  Normal   Started    46s (x3 over 2m45s)  kubelet            Started container liveness-exec
  Normal   Pulled     46s (x2 over 106s)   kubelet            Container image "kubernetes-register.superopsmsb.com/superopsmsb/busybox:1.28" already present on machine
  Warning  Unhealthy  16s (x9 over 2m36s)  kubelet            Liveness probe failed:
  Normal   Killing    16s (x3 over 2m16s)  kubelet            Container liveness-exec failed liveness probe, will be restarted
...

flask应用实践案例

查看资源对象文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 07_kubernetes_pod_exec_check.yaml
apiVersion: v1
kind: Pod
metadata:
  name: superopsmsb-liveness-exec
spec:
  containers:
  - name: flask-web
    image: kubernetes-register.superopsmsb.com/superopsmsb/flask_web:v0.1
    livenessProbe:
      exec:
        command: ['/bin/bash', '-c', '[ "$(curl -s 127.0.0.1/liveness)" == "OK" ]']
    注意：
    	这里面的/liveness 接口是容器自定义的接口地址，不是所有容器都支持的
    	当前的/liveness支持post方法，用于更改接口的状态，从而来模拟容器的检测效果
    	command 里面的命令解释器，不要乱用其他的shell,以sh为例，它会报如下错：
    		failed: /bin/sh: 1: [: xxx: unexpected operator
    	
创建资源对象
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 07_kubernetes_pod_exec_check.yaml
pod/superopsmsb-liveness-exec created

查看效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  get pod -o wide
NAME                        READY   STATUS    RESTARTS      AGE     IP          ...
superopsmsb-liveness-exec   1/1     Running   1 (53s ago)   2m43s   10.244.4.19

正常访问
[root@kubernetes-master1 /data/kubernetes/pod]# curl 10.244.4.19
Hello Flask-V0.1, 来访者ip: 10.244.0.0, 主机名: superopsmsb-liveness-exec, Pod地址: 10.244.4.19!
[root@kubernetes-master1 /data/kubernetes/pod]# curl 10.244.4.19/liveness
OK

修改状态值
[root@kubernetes-master1 /data/kubernetes/pod]# curl -XPOST -d 'liveness=Error' 10.244.4.19/liveness
[root@kubernetes-master1 /data/kubernetes/pod]# curl 10.244.4.19/liveness
Error

稍等数秒
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  describe pod superopsmsb-liveness-exec
...
Events:
  Type     Reason     Age               From               Message
  ----     ------     ----              ----               -------
  ...
  Warning  Unhealthy  4m5s              kubelet            Liveness probe failed: command "/bin/bash -c [ \"$(curl -s 127.0.0.1/liveness)\" == \"OK\" ]" timed out
  Warning  Unhealthy  6s (x3 over 26s)  kubelet            Liveness probe failed:
  Normal   Killing    6s                kubelet            Container demo failed liveness probe, will be restarted
	结果显示：
		探针探测失败
		
探针探测失败后，会通过重启pod的方式，让容器重新处于正常的状态
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl get pod
NAME                        READY   STATUS    RESTARTS        AGE
superopsmsb-liveness-exec   1/1     Running   1 (2m30s ago)   7m31s
结果显示：
	因为刚才执行了一次POST方法，所以重启了1次

小结

1.3.3 TCP探测

学习目标

这一节，我们从 配置解读、简单实践、小结 三个方面来学习。

配置解读

简介

	对于一些容器应用来说，如果该服务是通过通过进程的方式实现对容器内容开放服务的特性，那么我们就可以进行tcpsocket方法的请求探测，使用tcpsocket配置， kubelet 将尝试在指定端口上打开容器的套接字。如果可以建立连接，容器被认为是健康的，如果不能就认为是失败的，实际上就是检查端口。

属性解读

查看属性结构
[root@kubernetes-master1 ~]# kubectl  explain pod.spec.containers.livenessProbe.tcpSocket
KIND:     Pod
VERSION:  v1

RESOURCE: tcpSocket <Object>

DESCRIPTION:
     TCPSocket specifies an action involving a TCP port.

     TCPSocketAction describes an action based on opening a socket

FIELDS:
   host <string>
     Optional: Host name to connect to, defaults to the pod IP.

   port <string> -required-
     Number or name of the port to access on the container. Number must be in
     the range 1 to 65535. Name must be an IANA_SVC_NAME.
     注: IANA(The Internet Assigned Numbers Authority)互联网数字分配机构,是负责协调一些使Internet正常运作的机构。

简单实践

nginx的web服务检测1

查看资源对象文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 08_kubernetes_pod_tcpsocket_check.yaml
apiVersion: v1
kind: Pod
metadata:
  name: superopsmsb-tcpsocket-check
spec:
  containers:
  - name: nginx-web
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    # 定制容器服务可用性探测
    readinessProbe:
      tcpSocket:
        port: 80
    # 定制pod对象可用性探测
    livenessProbe:
      tcpSocket:
        port: 80
    注意：
        由于我们的镜像应用对外暴露的端口是80端口，所以我们要探测80端口

应用资源文件
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 08_kubernetes_pod_tcpsocket_check.yaml
pod/superopsmsb-tcpsocket-check created

查看效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  get pod
NAME                          READY   STATUS    RESTARTS   AGE
superopsmsb-tcpsocket-check   1/1     Running   0          7s

nginx的web服务检测2

修改资源对象文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 09_kubernetes_pod_tcpsocket_check_error.yaml
apiVersion: v1
kind: Pod
metadata:
  name: superopsmsb-tcpsocket-check
spec:
  containers:
  - name: nginx-web
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    # 定制容器服务可用性探测
    readinessProbe:
      tcpSocket:
        port: 888  # 设定为不存在的端口
    # 定制pod对象可用性探测
    livenessProbe:
      tcpSocket:
        port: 888  # 设定为不存在的端口
    注意：
        由于我们的镜像应用对外暴露的端口是80端口，所以我们要探测80之外的端口

应用资源文件
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 09_kubernetes_pod_tcpsocket_check_error.yaml
pod/superopsmsb-tcpsocket-check created

查看效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  get pod
NAME                          READY   STATUS    RESTARTS   AGE
superopsmsb-tcpsocket-check   0/1     Running   0          2s

查看资源状态
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  describe pod superopsmsb-tcpsocket-check
...
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  73s                default-scheduler  Successfully assigned default/superopsmsb-tcpsocket-check to kubernetes-node2
  Normal   Killing    43s                kubelet            Container nginx-web failed liveness probe, will be restarted
  Normal   Pulled     13s (x2 over 73s)  kubelet            Container image "kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1" already present on machine
  Normal   Created    13s (x2 over 73s)  kubelet            Created container nginx-web
  Normal   Started    13s (x2 over 72s)  kubelet            Started container nginx-web
  Warning  Unhealthy  3s (x14 over 72s)  kubelet            Readiness probe failed: dial tcp 10.244.4.21:888: connect: connection refused
  Warning  Unhealthy  3s (x4 over 63s)   kubelet            Liveness probe failed: dial tcp 10.244.4.21:888: connect: connection refused
  
查看重启情况
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  get pod
NAME                          READY   STATUS    RESTARTS      AGE
superopsmsb-tcpsocket-check   0/1     Running   2 (22s ago)   2m22s

小结

1.3.4 HTTP探测

学习目标

这一节，我们从 配置解读、简单实践、小结 三个方面来学习。

配置解读

简介

	对于一些容器应用来说，如果该服务是通过通过http的方式实现对容器内容开放web服务特性，那么我们就可以进行http方法的请求探测，如果探测成功，那么表示我们的http服务是正常的，否则就是失败的。

属性解读

查看属性结构
[root@kubernetes-master1 ~]# kubectl  explain pod.spec.containers.livenessProbe.httpGet
KIND:     Pod
VERSION:  v1

RESOURCE: httpGet <Object>

DESCRIPTION:
     HTTPGet specifies the http request to perform.

     HTTPGetAction describes an action based on HTTP Get requests.

FIELDS:
   host <string>
     Host name to connect to, defaults to the pod IP. You probably want to set
     "Host" in httpHeaders instead.

   httpHeaders  <[]Object>
     Custom headers to set in the request. HTTP allows repeated headers.

   path <string>
     Path to access on the HTTP server.

   port <string> -required-
     Name or number of the port to access on the container. Number must be in
     the range 1 to 65535. Name must be an IANA_SVC_NAME.

   scheme       <string>
     Scheme to use for connecting to the host. Defaults to HTTP.

简单实践

liveness探测效果

修改资源对象文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 10_kubernetes_pod_httpget_check.yaml
apiVersion: v1
kind: Pod
metadata:
  name: superopsmsb-httpget-check
spec:
  containers:
  - name: nginx-web
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    livenessProbe:
      httpGet:
        path: '/index.html'
        port: 80
      
创建资源对象
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 10_kubernetes_pod_httpget_check.yaml
pod/superopsmsb-httpget-check created

检查效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl get pod
NAME                        READY   STATUS    RESTARTS   AGE
superopsmsb-httpget-check   1/1     Running   0          30s

状态检查
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl describe pod superopsmsb-httpget-check
Name:               liveness-httpget-pod
...
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  ...
  Normal  Started    11s   kubelet            Started container nginx-web
...

尝试把资源清单文件的端口修改为不存在的，然后再次应用资源清单文件
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  delete -f 10_kubernetes_pod_httpget_check.yaml
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 10_kubernetes_pod_httpget_check.yaml

查看应用效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl describe pod superopsmsb-httpget-check
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  ...
  Warning  Unhealthy  6s (x6 over 86s)   kubelet            Liveness probe failed: Get "http://10.244.3.12:81/index.html": dial tcp 10.244.3.12:81: connect: connection refused
  Normal   Killing    6s (x2 over 66s)   kubelet            Container nginx-web failed liveness probe, will be restarted

readness探测实践

查看资源对象文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 11_kubernetes_pod_httpget_check.yaml
apiVersion: v1
kind: Pod
metadata:
  name: superopsmsb-httpget-check
spec:
  containers:
  - name: nginx-web
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    readinessProbe:
      httpGet:
        path: '/index.html'
        port: 81  # 故意找一个不存在的端口
        
应用资源清单文件
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 11_kubernetes_pod_httpget_check.yaml

检查状态
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  describe  pod superopsmsb-httpget-check
...
Events:
  Type     Reason     Age               From               Message
  ----     ------     ----              ----               -------
  ...
  Warning  Unhealthy  5s (x9 over 64s)  kubelet            Readiness probe failed: Get "http://10.244.4.26:81/index.html": dial tcp 10.244.4.26:81: connect: connection refused
  
查看服务效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl get pod
NAME                        READY   STATUS    RESTARTS   AGE
superopsmsb-httpget-check   0/1     Running   0          68s

小结

1.3.5 钩子实践

学习目标

这一节，我们从 poststart实践、prestop实践、小结 三个方面来学习。

poststart实践

属性简介

对于pod的流程启动，主要有两种钩子：
	postStart，容器创建完成后立即运行，不保证一定会于容器中ENTRYPOINT之前运行
	preStop，容器终止操作之前立即运行，在其完成前会阻塞删除容器的操作调用

钩子处理器实现方式：Exec 和 HTTP
	Exec，在钩子事件触发时，直接在当前容器中运行由用户定义的命令
	HTTP，在当前容器中向某Url发起HTTP请求

属性信息：kubectl explain pods.spec.initContainers.lifecycle

简单实践

查看资源对象文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 12_kubernetes_pod_poststart.yaml
apiVersion: v1
kind: Pod
metadata:
  name: superopsmsb-poststart
spec:
  containers:
  - name: busybox
    image: kubernetes-register.superopsmsb.com/superopsmsb/busybox:1.28
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh","-c","echo 'lifecycle poststart' > /tmp/poststart.html"]
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
注意：	
	如果资源文件中的质量命令属性很多，那么优先级最高的先执行，希望大家在编写命令的时候，观察依赖关系。

启动资源对象
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 12_kubernetes_pod_poststart.yaml
pod/superopsmsb-poststart created
查看效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  get pod
NAME                        READY   STATUS    RESTARTS   AGE
superopsmsb-poststart       1/1     Running   0          4s

文件效果
]# kubectl exec poststart -- ls /tmp                     
poststart.html
]# kubectl exec poststart -- cat /tmp/poststart.html
lifecycle poststart

查看效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  get pod
NAME                        READY   STATUS    RESTARTS   AGE
superopsmsb-poststart       1/1     Running   0          4s

文件效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl exec superopsmsb-poststart -- ls /tmp
poststart.html
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl exec superopsmsb-poststart -- cat /tmp/poststart.html
lifecycle poststart

prestop实践

属性解析

kubectl explain pods.spec.initContainers.lifecycle.preStop
功能：实现pod对象移除之前，我们需要做一些事情
实现方式：
    exec <Object>
    httpGet      <Object>
    tcpSocket    <Object>

钩子处理程序的日志不会在 Pod 事件中公开。 如果处理程序由于某种原因失败，它将播放一个事件。 对于 PostStart，这是 FailedPostStartHook 事件，对于 PreStop，这是 FailedPreStopHook 事件。 您可以通过运行 kubectl describe pod <pod_name> 命令来查看这些事件。

简单实践

	由于默认情况下，删除的动作和日志我们都没有办法看到，那么我们这里采用一种区间的方法，在删除动作之前，给本地目录创建第一个文件，输入一些内容
	
查看资源对象文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 13_kubernetes_pod_prestop.yaml
apiVersion: v1
kind: Pod
metadata:
  name: superopsmsb-prestop
spec:
  volumes:
  - name: message
    hostPath:
      path: /tmp
  containers:
  - name: nginx-web
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    volumeMounts:
    - name: message
      mountPath: /prestop/
    lifecycle:
      preStop:
        exec:
          command: ['/bin/sh', '-c', 'echo prestop Handler > /prestop/prestop']

应用资源定义文件
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 13_kubernetes_pod_prestop.yaml
pod/superopsmsb-prestop created

查看效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  get pod -o wide
NAME                    READY   STATUS        RESTARTS   AGE     IP            NODE               NOMINATED NODE   READINESS GATES
superopsmsb-prestop     1/1     Running       0          6s      10.244.4.27   kubernetes-node2   <none>           <none>

到node2节点上查看效果
[root@kubernetes-master1 /data/kubernetes/pod]# ssh root@10.0.0.16 "rm -rf /tmp/*"
[root@kubernetes-master1 /data/kubernetes/pod]# ssh root@10.0.0.16 "ls /tmp"
[root@kubernetes-master1 /data/kubernetes/pod]#

关闭资源对象文件
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  delete -f 13_kubernetes_pod_prestop.yaml
pod "superopsmsb-prestop" deleted

到node2节点上查看效果
[root@kubernetes-master1 /data/kubernetes/pod]# ssh root@10.0.0.16 "ls /tmp"
prestop
[root@kubernetes-master1 /data/kubernetes/pod]# ssh root@10.0.0.16 "cat /tmp/prestop"
prestop Handler

小结

1.4 Pod资源配额

1.4.1 资源配额

学习目标

这一节，我们从 属性解读、简单实践、小结 三个方面来学习。

属性解读

简介

	Kubernetes是分布式的容器管理平台，所有资源都有Node节点提供，而Node节点上运行着很多Pod业务有很多，在一个项目中，有的业务占用的资源比重大，有的小，想要高效的利用Node资源，必须进行资源限制，那么Pod的资源限制应该如何处理？
	对此，Kubernetes技术对Pod做了相应的资源配额设置，这些资源主要体现在：CPU和内存、存储，因为存储在k8s中有专门的资源对象来进行管控，所以我们在说到pod资源限制的时候，一般指的是 CPU和内存。

CPU
	kubernetes将一颗CPU的资源分为1000份，每份1m
	平常我们可以为一个容器设定占用的CPU是100~300m，即0.1-0.3个CPU
MEM	
	kubernetes以正常的状态来交付内存资源。
	平常我们可以为一个容器设定占用的MEM是500~1000Mi，由于内存资源消耗区别较大，该值可以适时调整。

资源配额

	Kubernetes中，对于每种资源的配额限定都需要两个参数：Resquests和Limits
申请配额(Requests)：
	业务运行时最小的资源申请使用量，该参数的值必须满足，若不满足，业务运行不起来。
最大配额(Limits)：
	业务运行时最大的资源允许使用量，该参数的值不能被突破，若突破，该业务的资源对象会被重启或删除等意外操作

属性解读

[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  explain pod.spec.containers.resources
KIND:     Pod
VERSION:  v1

RESOURCE: resources <Object>

DESCRIPTION:
     Compute Resources required by this container. Cannot be updated. More info:
     https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

     ResourceRequirements describes the compute resource requirements.

FIELDS:
   limits       <map[string]string>
     Limits describes the maximum amount of compute resources allowed. More
     info:
     https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

   requests     <map[string]string>
     Requests describes the minimum amount of compute resources required. If
     Requests is omitted for a container, it defaults to Limits if that is
     explicitly specified, otherwise to an implementation-defined value. More
     info:
     https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

资源管控对象

	kubernetes为了方便统一管理各种容器的资源使用情况，提供了一种资源限制对象 LimitRange，它可以针对我们的请求的资源进行简单的控制。

[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  explain LimitRange.spec.limits
KIND:     LimitRange
VERSION:  v1
...
FIELDS:
   default      <map[string]string>
     Default resource requirement limit value by resource name if resource limit
     is omitted.

   defaultRequest       <map[string]string>
     DefaultRequest is the default resource requirement request value by
     resource name if resource request is omitted.

   max  <map[string]string>
     Max usage constraints on this kind by resource name.

   maxLimitRequestRatio <map[string]string>
     MaxLimitRequestRatio if specified, the named resource must have a request
     and limit that are both non-zero where limit divided by request is less
     than or equal to the enumerated value; this represents the max burst for
     the named resource.

   min  <map[string]string>
     Min usage constraints on this kind by resource name.

   type <string> -required-
     Type of resource that this limit applies to.

简单实践

资源管控对象

查看资源对象文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 14_kubernetes_pod_limitrange.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: superopsmsb-limitrange
spec:
  limits:
  - max:
      cpu: "700m"
      memory: "1Gi"
    min:
      cpu: "300m"
      memory: "100Mi"
    default:
      cpu: "700m"
      memory: "900Mi"
    defaultRequest:
      cpu: "310m"
      memory: "111Mi"
    type: Container

创建资源配额限制
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 14_kubernetes_pod_limitrange.yaml
limitrange/superopsmsb-limitrange created

查看效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  describe limitranges
Name:       superopsmsb-limitrange
Namespace:  default
Type        Resource  Min    Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------  ---    ---   ---------------  -------------  -----------------------
Container   memory    100Mi  1Gi   111Mi            900Mi          -
Container   cpu       300m   700m  310m             700m           -

默认资源配置

创建资源对象
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 01_kubernetes_pod_run.yaml
pod/superopsmsb-nginx created

查看资源使用的现状
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  describe pod superopsmsb-nginx
...
Containers:
  nginx:
    ...
    Limits:
      cpu:     700m
      memory:  900Mi
    Requests:
      cpu:        310m
      memory:     111Mi

定制资源使用

查看资源对象文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 15_kubernetes_pod_limitrequest.yaml
apiVersion: v1
kind: Pod
metadata:
  name: superopsmsb-limitrequest
spec:
  containers:
  - name: nginx-web
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    resources:
      requests:
        memory: "600Mi"
        cpu: "500m"
      limits:
        memory: "700Mi"
        cpu: "800m"

创建资源对象
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 15_kubernetes_pod_limitrequest.yaml
pod/superopsmsb-limitrequest created

查看资源对象使用效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  describe pod superopsmsb-limitrequest
...
Containers:
  nginx-web:
    ...
    Limits:
      cpu:     600m
      memory:  700Mi
    Requests:
      cpu:        500m
      memory:     600Mi
      
注意：
	一旦资源使用的量超出默认的预期值，则会发生报错

小结

1.4.2 资源质量

学习目标

这一节，我们从 基础知识、简单实践、小结 三个方面来学习。

基础知识

场景

	kubernetes针对这些资源的使用，虽然进行了资源的限制，但是资源搭配的程度是否平衡，也影响到一部分的资源使用性能，所以kubernetes提供了一个资源服务质量的东西，来帮助我们确认效果。

QoS简介

	QoS是作用在 Pod 上的一个配置，当 Kubernetes 创建一个 Pod 时，它就会给这个 Pod 分配一个 QoS 等级，可以是以下等级之一：
Guaranteed等级：
	Pod内的每个容器同时设置了CPU和内存的requests和limits  而且值必须相等。
	这样的话pod在运行时候有了稳定的资源保障措施。
Burstable等级：
	pod至少有一个容器设置了cpu或内存的requests和limits，不满足 Guarantee 等级的要求。
	这样的话pod在运行时候虽然有了资源保障措施，但是可能出现意外资源不足的情况。
BestEffort等级：
	没有任何一个容器设置了requests或limits的属性。
	那就采用
		默认的资源配置 - 后期运行可能因为资源限制导致无法运行
		不做资源配置措施 - 后期因为资源抢占导致无法运行

简单实践

Guaranteed实践

查看资源对象文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 16_kubernetes_pod_guaranteed.yaml
apiVersion: v1
kind: Pod
metadata:
  name: superopsmsb-guaranteed
spec:
  containers:
  - name: nginx-web
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    resources:
      requests:
        memory: "512Mi"
        cpu: "500m"
      limits:
        memory: "512Mi"
        cpu: "500m"
        
应用资源对象
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl apply -f 16_kubernetes_pod_guaranteed.yaml
pod/superopsmsb-guaranteed created

查看资源对象效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  describe pod superopsmsb-guaranteed  | grep QoS
QoS Class:                   Guaranteed

Burstable实践

查看资源对象文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 17_kubernetes_pod_burstable.yaml
apiVersion: v1
kind: Pod
metadata:
  name: superopsmsb-burstable
spec:
  containers:
  - name: nginx-web
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    resources:
      requests:
        memory: "512Mi"
        cpu: "500m"
        
应用资源对象
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 17_kubernetes_pod_burstable.yaml
pod/superopsmsb-burstable created

查看资源对象效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  describe pod superopsmsb-burstable  | grep QoS
QoS Class:                   Burstable

BestEffort实践

为了演示成功，我们需要首先将默认的资源分配策略去除
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl delete -f 15_kubernetes_pod_limitrequest.yaml

查看资源对象文件
[root@kubernetes-master1 /data/kubernetes/pod]# cat 18_kubernetes_pod_besteffort.yaml
apiVersion: v1
kind: Pod
metadata:
  name: superopsmsb-besteffort
spec:
  containers:
  - name: nginx-web
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
        
应用资源对象
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  apply -f 18_kubernetes_pod_besteffort.yaml
pod/superopsmsb-besteffort created

查看资源对象效果
[root@kubernetes-master1 /data/kubernetes/pod]# kubectl  describe pod superopsmsb-besteffort | grep QoS
QoS Class:                   BestEffort

小结