核心概念
（一）Pod
K8s最小单位不是以容器为单位,而是以Pod为单位.Pod是所有业务类型的基础,k8s 不会直接处理容器，而是 Pod，Pod 是由一个或多个 container 组成
一个Pod是一组Docker的container 的集合，也就是Pod内部可以有多个容器存在，不是一个Pod代表一个容器.
一个Pod中的所有容器是共享网络的,假如说有A,B,C三个容器都在Pod中,我现在A容器监听了80端口,那么B ,C这两个容器也能得到80端口.
Pod生命周期是短暂的,不是一直存在的,比如说我服务器重启了,那么这个Pod就死了,就是一个新的Pod了.
1．为什么最小单元是Pod而不是容器
docker设计是单进程的,一个容器就是一个进程.
一个docker容器里面运行的是一个应用程序,当然也可以运行多个,但是这样的话不好管理 .
为了解决docker一个容器运行多个程序不方便管理的特点,就有了pod
pod是多进程的设计,可以运行多个应用程序.
pod设计方式
pod里面有多个docker容器,每个docker容器运行一个应用程序.
pod的存在也是为了亲密性应用
什么是亲密性应用
1.两个应用或者多个应用之间要相互进行交互. 比如一个pod里面有两个容器, 容器A和容器B有交互行为,比如说容器A调用容器B ,或者是容器A是读,容器B是写操作.
2.网络之间的调用,举例,比如说一个pod里面多个容器,A容器是Nginx,B容器是Java项目,那么A容器调用B容器操作就是网络之间的调用, 如果你两个容器不在一个Pod里面的话,那么就需要IP外网调用了.如果A容器和B容器在一个pod里面就可以直接通过127.0.0.1或者是通过socket调用就可以了,这么做肯定更加方便.
亲密性应用性能更高,更加方便
2．pod的实现机制
是这两个机制:
\1. 共享网络
\2. 共享存储
a）共享网络
Pod内部是docker容器,docker容器本身是相互隔离的,用的linux的namespace或者是group进行隔离.
但是pod之间的docker容器是共享网络的,这个是怎么实现的呢?
就让多个容器在同一个linux的namespace里面就可以了.这样就可以做到网络的共享了.
这个是在pod中怎么实现的呢?
过程是首先通过Pod创建1容器和2容器,首先先创建一个叫Pause的容器,这个Pause容器可以理解为info容器,就是根容器,下面就会创建业务容器,就是1容器和2容器.
会把业务容器(1容器和2容器)加入到info容器里面.通过info容器进行管理,所以这些容器都是在同一个namespace下面的.就可以实现网络共享了.
在info容器里面会独立出一个ip mac port ,就能实现网络共享的机制了.
b）共享存储
pod实现机制,共享存储,在pod容器的操作中肯定会产生很多的数据,如果数据一直使用的话,肯定是要做持久化的操作的.为下次继续使用, 如果你不做持久化的操作之后,下次再使用肯定就没有了.
pod进行持久化数据可能会有日志数据,业务数据(增删改查操作数据),这些数据做持久化操作,后面才能使用.如果你不做持久化操作的话,那么后面再使用就不存在了.
假如说K8s 有三个节点,操作的时候node1机器故障了,那么node1机器的数据会转移到node2节点上(这个其实是镜像的转移).如果你不对日志数据业务数据做持久化操作的话,那么node2机器故障转移过来的新容器就无法获取之前在node1运行的容器里面的日志了.
所以K8s有持久化存储,就是Volumn数据卷.Volumn数据卷.Volumn数据卷就是类似数据库的一种东西. node2就可以从Volumn数据卷读取到node1持久化的数据了.
3．镜像拉取策略
在Kubernetes中运行容器时，需要为容器获取镜像。Pod中容器的镜像有三个来源，即Docker公共镜像仓库、私有镜像仓库和本地镜像。当在内网使用的Kubernetes场景下，就需要搭建和使用私有镜像仓库。Pod支持三种镜像拉取策略，在配置文件中通过imagePullPolicy字段设置镜像拉取策略：
IfNotPresent(默认策略)：仅在本地镜像不存在时，才会进行镜像拉取
Always：不管本地是否存在镜像都会进行一次拉取
Never：pod不管本地是否存在镜像都不会进行拉取,需要程序员手动去拉取
这里有需要注意的点：镜像拉取策略的默认值IfNotPresent，但:lastest标签的镜像默认为Always。所以生产环境中避免使用:lastest标签。还有就是拉取镜像时docker会进行校验，如果镜像中的MD5码没有变，则不会拉取镜像数据。
4．资源限制
Kubernetes通过cgroups来限制容器的CPU和内存等计算资源，在创建Pod时，可以为Pod中的每个容器设置资源请求(request)和资源限制(limit)，资源请求是容器需要的最小资源要求，资源限制为容器所能使用的资源上限。CPU的单位是核(core)，内存(Memory)的单位是字节(byte)。
假如说我现在有三个Node机器,我创建一个pod,就会给pod调度到某个node节点上去,pod在调度过程中有这么一个特点,
比如说我node1机器的剩余资源是 2核心4G内存
node2机器的剩余资源是 4核心16G内存
node3机器的剩余资源是 1核心2G内存
而我pod在调度的时候需要至少2核心4G内存才能支撑操作,那么pod在调度的时候,发现node3资源无法满足. 那么就不调度node3机器
也就是说pod调度根据资源限制进行调度,如果node机器不满足pod资源,那么pod就不往这个node机器上去调度.这样就保证pod的最大化的合理应用,这就是资源限制了.
5．Pod工作方式
在Kubernetes中一般不会直接创建一个独立的Pod，这是因为Pod是临时存在的一个实体。当直接创建一个独立的Pod时，如果缺少资源或者所被调度到的Node失败，则Pod会直接被删除。这里需要注意的是，重起Pod和重起Pod中的容器不是一个概念，Pod自身不会运行，它只是容器所运行的一个环境。Pod本身没有自愈能力，如果Pod所在的Node失败，或者如果调度操作本身失败，则Pod将会被删除；同样的，如果缺少资源，Pod也会失败。Kubernetes使用高层次的抽象，即控制器来管理临时的Pod。通过控制器能够创建和管理多个Pod，并在集群范围内处理副本、部署和提供自愈能力。
6．重启策略
比如说我pod里面有很多容器,当容器终止了,或者退出了还要做什么操作,这就是重启策略
Pod支持三种重启策略，需要在配置文件中通过restartPolicy字段设置重启策略：
Always(默认)：只要退出就会重启,用在不断提供服务的地方,比如说nginx(只有启动状态才能提供服务).
OnFailure：只有在异常退出的时候（即exit code不等于0时），才会重启,适合比如说有批量任务,就是只执行一次,执行完了就不执行了.
Never：只要容器终止退出就不再重启
7．健康检查
[root@zjj101 config]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-f89759699-rh5lk 1/1 Running 0 17h
看到虽然容器是running状态的,但是可能这个容器是不健康的,比如说Java项目出现内存溢出问题了,不能提供服务了,但是通过kubectl get pods命令看到它可能也是running状态的(因为进程还存在).
所以kubectl get pods不能看到容器是否能正常提供服务.
我们可以到应用层面健康检查来看看容器是否是真的正常工作. 比如说通过ip端口访问容器里的应用.
k8s检查有两种检查机制 readiness和liveness
liveness 是存活检查,如果检查失败,就杀死容器,根据pod里面的restartPolicy(程序员配置的重启策略)来进行操作
readiness是就绪检查, 如果检查失败,k8s就会把这个pod从当前容器中移除掉,用其它容器去提供服务.
Probe支持以下三种检查方式
\1. httpGet: 发送HTTP请求,返回200-400范围状态码为成功
\2. exec : 执行shell命令返回状态码是0就为成功
\3. tcpSocket : 发起TCP Socket建立连接,如果建立了就表示成功了.
8．终止Pod
在集群中，Pod代表运行的进程，但不再需要这些进程时，如何优雅的终止这些进程是非常重要的。当用户请求删除一个Pod时，Kubernetes将会发送一个终止信号给每个容器，一旦过了优雅期，就会发送kill信号，从而通过APIServer删除Pod。通常默认的优雅退出时间为30s。缓慢关闭的Pod依然可以对外继续服务，直到负载均衡器将其移除，当超过优雅的退出时间，在Pod中任何正在运行的进程都会被kill。
9．Pod的生命周期
1、Pending
Pod已经被Kubernetes系统接受，但是还有一个或者多个容器镜像未被创建。这包括Pod正在被调度和从网络上下载镜像的时间。
2、Running
Pod已经被绑定到了一个Node，所有容器已经被创建，至少有一个容器在运行
3、Succeeded
在Pod中所有容器已经被成功停止，并且不再重启
4、Failed
在Pod中所有容器已经被终止，并且至少有一个容器是非正常终止的，即容器以非零状态退出或者被系统强行终止的。
5、Unknown
Pod在某些原因下不能被获取。通常是网络问题。
10．Pod调度策略
我用 kubectl apply -f .yml 创建一个pod ,
我可以从kubectl get pods 去查看pod
这个Pod可能会分配到node1机器上,可能会分配到Node2机器上.
