Docker

docker的工作原理

docker是一个client-server结构的系统，docker守护进程运行在宿主机上，守护进程从客户端接受命令并管理运行在主机上的容器，容器是一个运行时环境，这就是我们说的集装箱

docker组成部分

1、docker client 客户端，为用户提供一系列可执行命，用户用这些命令实现跟docker daemon交互

2、docker daemon 守护进程，在宿主机后台运行，等待接收来自客户端的请求消息

3、docker image 镜像

4、docker container 容器 系统级别的服务

docker三大核心概念

1、镜像：轻量级独立的安装包

2、容器：基于镜像创建的一个实例化的镜像程序

3、镜像仓库：用于存放镜像的地方

docker centos镜像小的原因

所有镜像容器都共享宿主机的kernel内核。

镜像分层结构以及为什么要使用镜像分层结构

新的镜像其实是从base镜像一层一层叠加生成的，每安装一个软件，dockerfile中使用RUM命令，就会在现有镜像的基础上增加一层，这样一层一层的叠加最后构成完整镜像。所以我们docker pull

拉取镜像的时候发现是一层一层拉取得。

分层的好处：共享资源，比如有多个镜像都从相同的base镜像构建而来，那么docker host只需要在磁盘上保存一份base镜像，同时，内存中也只需要加载一份base镜像，就可以为所有容器服务了。

而且镜像的每一层都可以被共享。

dockerfile的整个构建镜像的过程

1、创建一个目录用于存放应用程序以及构建过程中使用的各个文件

2、在这个目录下创建一个Dockerfile文件，一般命名即为Dockerfile。

3、编写dockerfile，编写指令。如使用FROM指令制定基础镜像，COPY指令复制文件，RUN指定运行的命令，ENV设置环境变量，EXPOSE指定容器要暴露的端口，WORKDIR设置当前工作目录，

CMD容器启动时命令。

4、Dockerfile编写完成就可以构建镜像了，使用docker build -t 镜像名：tag .命令来构建，最后的.表示当前目录，docker会默认寻找当前目录下dockerfile文件来构建，如果不使用默认，可以

使用-f来指定dockerfile文件，如：docker build -t 镜像名：tag -f /xxx/xxx/xxx/Dockerfile

5、使用docke build命令构建后，docker就会将当前目录下所有的文件发送给docker daemon，顺序执行dockerfile文件里的指令，在这个过程中会生成临时容器，在临时容器里面安装RUN指定的命令，

安装成功后，docker底层会使用类似docker commit命令来将容器保存为镜像，然后删除临时容器。以此类推，一层层的构建镜像，运行临时容器软件，直到最后镜像构建成功。

dockerfile构建镜像出现异常排查

首先dockerfile是一层一层的构建镜像的，期间会产生一个或多个临时容器，构建过程中其实就是在临时容器里面安装应用，如果临时容器安装应用出现异常会导致镜像构建失败，这时容器虽然被清理掉，

但是期间构建的中间镜像还在，可以根据异常时上一层已经构建好的临时镜像，将临时镜像运行为容器，然后在容器里运行安装命令来具体定位。

dockerfile命令

FROM 指定基础镜像（必须为第一个指令，因为需要指定使用哪个基础镜像来构建镜像）；

MAINTAINER 设置镜像作者相关信息，如作者名字，日期，邮件，联系方式等；

COPY 复制文件到镜像；

ADD 复制文件到镜像（ADD与COPY的区别在于，ADD会自动解压tar、zip、tgz、xz等归档文件，而COPY不会，同时ADD指令还可以接一个url下载文件地址，一般建议使用COPY复制文件即可，文件在宿主机上

是什么样子复制到镜像里面就是什么样子这样比较好）；

ENV 设置环境变量；

EXPOSE 暴露容器进程的端口，仅仅是提示别人容器使用的哪个端口，没有过多作用；

VOLUME 数据卷持久化，挂载一个目录；

WORKDIR 设置工作目录，如果目录不在，则会自动创建目录；

RUN 在容器中运行命令，RUN指令会创建新的镜像层，RUN指令经常被用于安装软件包；

CMD 指定容器启动时默认运行哪些命令，如果有多个CMD，则只有最后一个生效，另外，CMD指令可以被docker run之后的参数替换；

ENTRYOINT 指定容器启动时运行哪些命令，如果有多个ENTRYOINT，则只有最后一个生效，另外，如果Dockerfile中同时存在CMD和ENTRYOINT，那么CMD或docker run之后的参数将被当做参数传递给ENTRYOINT；

K8S

K8S组件

master和node两种节点，master负责集群管理，node节点是容器真正运行的地方。

master节点包括：kube-api-server、kube-controller-manager、kube-scheduler、etcd。

node：kubelet、kube-proxy、container-runtime。

kubelet功能和作用

1、节点管理。kubelet启动时会向api-server进行注册，然后会定时的向api-server汇报本节点信息状态，资源使用状态等，这样master就能够知道node节点的资源剩余，节点是否失联等等相关的信息了。

master知道了整个集群所有节点的资源情况，这对于 pod 的调度和正常运行至关重要。

2、pod管理。kubelet负责维护node节点上pod的生命周期，当kubelet监听到master的下发到自己节点的任务时，比如要创建、更新、删除一个pod，kubelet 就会通过CRI（容器运行时接口）插件来调用

不同的容器运行时来创建、更新、删除容器；常见的容器运行时有docker、containerd、rkt等等这些容器运行时，我们最熟悉的就是docker了，但在新版本的k8s已经弃用docker了，k8s1.24版本中已经

使用containerd作为容器运行时了。

3、容器健康检查

pod中可以定义启动探针、存活探针、就绪探针等3种，我们最常用的就是存活探针、就绪探针，kubelet 会定期调用容器中的探针来检测容器是否存活，是否就绪，如果是存活探针，则会根据探测结果对

检查失败的容器进行相应的重启策略；

4、Metrics server资源监控。在node节点上部署Metrics Server用于监控node节点、pod的CPU、内存、文件系统、网络使用等资源使用情况，而kubelet则通过Metrics Server获取所在节点及容器的上的数据。

pod特点

1、每个pod就像一个独立的逻辑机器，k8s会为每个pod分配一个集群内部唯一的IP地址，所以每个pod都拥有自己的IP地址、主机名、进程等；

2、一个pod可以包含1个或多个容器，1个容器一般被设计成只运行1个进程，1个pod只可能运行在单个节点上，即不可能1个pod跨节点运行，pod的生命周期是短暂，也就是说pod可能随时被消亡（如节点异常，

pod异常等情况）；

3、每一个pod都有一个特殊的被称为"根容器"的pause容器，也称info容器，pause容器对应的镜像属于k8s平台的一部分，除了pause容器，每个pod还包含一个或多个跑业务相关组件的应用容器；

4、一个pod中的容器共享network命名空间；

5、一个pod里的多个容器共享pod IP，这就意味着1个pod里面的多个容器的进程所占用的端口不能相同，否则在这个pod里面就会产生端口冲突；既然每个pod都有自己的IP和端口空间，那么对不同的两个pod来

说就不可能存在端口冲突；

6、应该将应用程序组织到多个pod中，而每个pod只包含紧密相关的组件或进程；

7、pod是k8s中扩容、缩容的基本单位，也就是说k8s中扩容缩容是针对pod而言而非容器。

pause容器作用

每个pod里运行着一个特殊的被称之为pause的容器，也称根容器，而其他容器则称为业务容器；创建pause容器主要是为了为业务容器提供 Linux命名空间，共享基础：包括 pid、icp、net 等，以及启动

init 进程，并收割僵尸进程；这些业务容器共享pause容器的网络命名空间和volume挂载卷，当pod被创建时，pod首先会创建pause容器，从而把其他业务容器加入pause容器，从而让所有业务容器都在同

一个命名空间中，这样可以就可以实现网络共享。pod还可以共享存储，在pod级别引入数据卷volume，业务容器都可以挂载这个数据卷从而实现持久化存储。

pod的重启策略

可以通过restartPolicy字段配置pod重启容器的策略

Always: 当容器终止退出后，总是重启容器，默认策略就是Always。

OnFailure: 当容器异常退出，退出状态码非0时，才重启容器。

Never: 当容器终止退出，不管退出状态码是什么，从不重启容器。

pod的镜像拉取策略

pod镜像拉取策略可以通过imagePullPolicy字段配置镜像拉取策略，主要有3中镜像拉取策略

IfNotPresent: 默认值，镜像在node节点宿主机上不存在时才拉取。

Always: 总是重新拉取，即每次创建pod都会重新从镜像仓库拉取一次镜像。

Never: 永远不会主动拉取镜像，仅使用本地镜像，需要你手动拉取镜像到node节点，如果node节点不存在镜像则pod启动失败。

pod的存活探针

kubernetes可以通过存活探针检查容器是否还在运行，可以为pod中的每个容器单独定义存活探针，kubernetes将定期执行探针，如果探测失败，将杀死容器，并根据restartPolicy策略来决定是否重启容器，

kubernetes提供了3种探测容器的存活探针

httpGet：通过容器的IP、端口、路径发送http 请求，返回200-400范围内的状态码表示成功。

exec：在容器内执行shell命令，根据命令退出状态码是否为0进行判断，0表示健康，非0表示不健康。

TCPSocket：与容器的IP、端口建立TCP Socket链接，能建立则说明探测成功，不能建立则说明探测失败。

存活探针的属性参数

initialDelaySeconds：表示在容器启动后延时多久秒才开始探测；

periodSeconds：表示执行探测的频率，即间隔多少秒探测一次，默认间隔周期是10秒，最小1秒；

timeoutSeconds：表示探测超时时间，默认1秒，最小1秒，表示容器必须在超时时间范围内做出响应，否则视为本次探测失败；

successThreshold：表示最少连续探测成功多少次才被认定为成功，默认是1，对于liveness必须是1，最小值是1；

failureThreshold：表示连续探测失败多少次才被认定为失败，默认是3，连续3次失败，k8s 将根据pod重启策略对容器做出决定；

注意：定义存活探针时，一定要设置initialDelaySeconds属性，该属性为初始延时，如果不设置，默认容器启动时探针就开始探测了，这样可能会存在

应用程序还未启动就绪，就会导致探针检测失败，k8s就会根据pod重启策略杀掉容器然后再重新创建容器的莫名其妙的问题。

在生产环境中，一定要定义一个存活探针。

pod的就绪探针

httpGet：通过容器的IP、容器的端口以及路径来发送http get请求，返回200-400范围内的状态码表示请求成功。

exec：在容器内执行shell命令，它根据shell命令退出状态码是否为0进行判断，0表示健康，非0表示不健康。

TCPSocket：通过容器的IP、端口建立TCP Socket链接，能正常建立链接，则说明探针成功，不能正常建立链接，则探针失败。

就绪探针的属性参数

initialDelaySeconds：延时秒数，即容器启动多少秒后才开始探测，不写默认容器启动就探测；

periodSeconds ：执行探测的频率（秒），默认为10秒，最低值为1；

timeoutSeconds ：超时时间，表示探测时在超时时间内必须得到响应，负责视为本次探测失败，默认为1秒，最小值为1；

failureThreshold ：连续探测失败的次数，视为本次探测失败，默认为3次，最小值为1次；

successThreshold ：连续探测成功的次数，视为本次探测成功，默认为1次，最小值为1次；

pod创建过程

情况一、如果面试官问的是使用kubectl run命令创建的pod，可以这样说：

#注意：kubectl run 在旧版本中创建的是deployment，但在新的版本中创建的是pod则其创建过程不涉及deployment

如果是单独的创建一个pod，则其创建过程是这样的：

1、首先，用户通过kubectl或其他api客户端工具提交需要创建的pod信息给apiserver；

2、apiserver验证客户端的用户权限信息，验证通过开始处理创建请求生成pod对象信息，并将信息存入etcd，然后返回确认信息给客户端；

3、apiserver开始反馈etcd中pod对象的变化，其他组件使用watch机制跟踪apiserver上的变动；

4、scheduler发现有新的pod对象要创建，开始调用内部算法机制为pod分配最佳的主机，并将结果信息更新至apiserver；

5、node节点上的kubelet通过watch机制跟踪apiserver发现有pod调度到本节点，尝试调用docker启动容器，并将结果反馈apiserver；

6、apiserver将收到的pod状态信息存入etcd中。

至此，整个pod创建完毕。

情况二、如果面试官说的是使用deployment来创建pod，则可以这样回答：

1、首先，用户使用kubectl create命令或者kubectl apply命令提交了要创建一个deployment资源请求；

2、api-server收到创建资源的请求后，会对客户端操作进行身份认证，在客户端的~/.kube文件夹下，已经设置好了相关的用户认证信息，

这样api-server会知道我是哪个用户，并对此用户进行鉴权，当api-server确定客户端的请求合法后，就会接受本次操作，并把相关

的信息保存到etcd中，然后返回确认信息给客户端。

3、apiserver开始反馈etcd中过程创建的对象的变化，其他组件使用watch机制跟踪apiserver上的变动。

4、controller-manager组件会监听api-server的信息，controller-manager是有多个类型的，比如Deployment Controller, 它的作用就

是负责监听Deployment，此时Deployment Controller发现有新的deployment要创建，那么它就会去创建一个ReplicaSet，一个ReplicaSet

的产生，又被另一个叫做ReplicaSet Controller监听到了，紧接着它就会去分析ReplicaSet的语义，它了解到是要依照ReplicaSet的template

去创建Pod, 它一看这个Pod并不存在，那么就新建此Pod，当Pod刚被创建时，它的nodeName属性值为空，代表着此Pod未被调度。

5、调度器Scheduler组件开始介入工作，Scheduler也是通过watch机制跟踪apiserver上的变动，发现有未调度的Pod，则根据内部算法、

节点资源情况，pod定义的亲和性反亲和性等等，调度器会综合的选出一批候选节点，在候选节点中选择一个最优的节点，然后将pod绑定该该

节点，将信息反馈给api-server。

6、kubelet组件布署于Node之上，它也是通过watch机制跟踪apiserver上的变动，监听到有一个Pod应该要被调度到自身所在Node上来，

kubelet首先判断本地是否在此Pod，如果不存在，则会进入创建Pod流程，创建Pod有分为几种情况，第一种是容器不需要挂载外部存储，

则相当于直接docker run把容器启动，但不会直接挂载docker网络，而是通过CNI调用网络插件配置容器网络，如果需要挂载外部存储，

则还要调用CSI来挂载存储。kubelet创建完pod，将信息反馈给api-server，api-servier将pod信息写入etcd。

7、Pod建立成功后，ReplicaSet Controller会对其持续进行关注，如果Pod因意外或被我们手动退出，ReplicaSet Controller会知道，

并创建新的Pod，以保持replicas数量期望值。

pod的终止过程

1、用户向apiserver发送删除pod对象的命令；

2、apiserver中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead；

3、将pod标记为terminating状态；

4、kubectl在监控到pod对象为terminating状态了就会启动pod关闭过程；

5、endpoint控制器监控到pod对象的关闭行为时将其从所有匹配到此endpoint的server资源endpoint列表中删除；

6、如果当前pod对象定义了preStop钩子处理器，则在其被标记为terminating后会意同步的方式启动执行；

7、pod对象中的容器进程收到停止信息；

8、宽限期结束后，若pod中还存在运行的进程，那么pod对象会收到立即终止的信息；

9、kubelet请求apiserver将此pod资源的宽限期设置为0从而完成删除操作，此时pod对用户已不可见。

pod的生命周期有哪几种

Pending（挂起）：API server已经创建pod，但是该pod还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程；

Running（运行中）：Pod内所有的容器已经创建，且至少有一个容器处于运行状态、正在启动括正在重启状态；

Succeed（成功）：Pod内所有容器均已退出，且不会再重启；

Failed（失败）：Pod内所有容器均已退出，且至少有一个容器为退出失败状态

Unknown（未知）：某于某种原因apiserver无法获取该pod的状态，可能由于网络通行问题导致；