1、Kubernetes 与 Docker 有什么关系？
众所周知，Docker 提供容器的生命周期管理和 Docker 镜像构建运行时容器。但是，由于这些单独的容器有时必须跨主机通信，这时我们需要使用 Kubernetes 来解决这个问题。
因此，我们说 Docker 构建容器，但这些容器通过 Kubernetes 来进行跨主机相互通信。我们还可以使用 Kubernetes 手动关联和编排在多个主机上运行的容器。
2、k8s 创建一个pod的详细流程，涉及的组件怎么通信的？
k8s 创建一个 Pod 的详细流程如下：
(1) 客户端提交创建请求，可以通过 api-server 提供的 restful 接口，或者是通过 kubectl 命令行工具，支持的数据类型包括 JSON 和 YAML。 client ---create pod---> apiserver
(2) api-server 处理用户请求，将 pod 信息存储至 etcd 中。 apiserver ------> etcd
(3) kube-scheduler 通过 api-server 提供的接口监控到未绑定的 pod，尝试为pod分配node节点，主要分为两个阶段，预选阶段和优选阶段，其中预选阶段是遍历所有的node节点，根据策略筛选出候选节点，而优选阶段是在第一步的基础上，为每一个候选节点进行打分，分数最高者胜出。
apiserver-----监听到未绑定的pod，然后交给scheduler分配node-----> scheduler
apiserver<----scheduler分配好node，然后通知apiserver------ scheduler
(4) 选择分数最高的节点，进行 pod binding 操作，并将结果存储至 etcd 中。
apiserver ----------> etcd
(5) 随后目标节点的 kubelet 进程通过 api-server 提供的接口监测到 kube-scheduler 产生的 pod 绑定事件，根据绑定下载镜像并启动容器。
整个事件流可以参考下图：
3.kubelet 监控 Node 节点资源使用是通过什么组件来实现的？
这道题主要考察 cAdvisor 组件
开源软件 cAdvisor 是用于监控容器运行状态的利器之一，在 Kubernetes 系统中，cAdvisor 已被默认集成到 kubelet 组件内，当 kubelet 服务启动时，它会自动启动 cAdvisor 服务，然后 cAdvisor 会实时采集所在节点的性能指标及在节点上运行的容器的性能指标。kubelet 的启动参数 --cadvisor-port 可自定义 cAdvisor 对外提供服务的端口号，默认是 4194。
4、什么是 Heapster？
Heapster 是由每个节点上运行的 Kubelet 提供的集群范围的数据聚合器。
此容器管理工具在 Kubernetes 集群上本机支持，并作为 Pod 运行，就像集群中的任何其他 Pod 一样。因此，它基本上可以发现集群中的所有节点，并通过本机上 Kubernetes 代理查询集群中 Kubernetes 节点的使用信息。
5、 容器和主机部署应用的区别是什么？
容器的中心思想就是秒级启动；一次封装、到处运行；这是主机部署应用无法达到的效果，但同时也更应该注重容器的数据持久化问题。
另外，容器部署可以将各个服务进行隔离，互不影响，这也是容器的另一个核心概念。
6、请你说一下kubenetes针对pod资源对象的健康监测机制？
K8s中对于pod资源对象的健康状态检测，提供了三类probe（探针）来执行对pod的健康监测：
1） livenessProbe探针
可以根据用户自定义规则来判定pod是否健康，如果livenessProbe探针探测到容器不健康，则kubelet会根据其重启策略来决定是否重启，如果一个容器不包含livenessProbe探针，则kubelet会认为容器的livenessProbe探针的返回值永远成功。
2） ReadinessProbe探针
同样是可以根据用户自定义规则来判断pod是否健康，如果探测失败，控制器会将此pod从对应service的endpoint列表中移除，从此不再将任何请求调度到此Pod上，直到下次探测成功。
3） startupProbe探针
启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针kill掉，这个问题也可以换另一种方式解决，就是定义上面两类探针机制时，初始化时间定义的长一些即可。
每种探测方法能支持以下几个相同的检查参数，用于设置控制检查时间：
initialDelaySeconds：初始第一次探测间隔，用于应用启动的时间，防止应用还没启动而健康检查失败
periodSeconds：检查间隔，多久执行probe检查，默认为10s；
timeoutSeconds：检查超时时长，探测应用timeout后为失败；
successThreshold：成功探测阈值，表示探测多少次为健康正常，默认探测1次。
上面两种探针都支持以下三种探测方法：
1）Exec：通过执行命令的方式来检查服务是否正常，比如使用cat命令查看pod中的某个重要配置文件是否存在，若存在，则表示pod健康。反之异常。
Exec探测方式的yaml文件语法如下：
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秒
在上面的配置文件中，探测机制为在容器运行5秒后，每隔五秒探测一次，如果cat命令返回的值为“0”，则表示健康，如果为非0，则表示异常。
2）Httpget：通过发送http/htps请求检查服务是否正常，返回的状态码为200-399则表示容器健康（注http get类似于命令curl -I）。
Httpget探测方式的yaml文件语法如下：
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秒
上述配置文件中，探测方式为项容器发送HTTP GET请求，请求的是8080端口下的healthz文件，返回任何大于或等于200且小于400的状态码表示成功。任何其他代码表示异常。
3）tcpSocket：通过容器的IP和Port执行TCP检查，如果能够建立TCP连接，则表明容器健康，这种方式与HTTPget的探测机制有些类似，tcpsocket健康检查适用于TCP业务。
tcpSocket探测方式的yaml文件语法如下：
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
在上述的yaml配置文件中，两类探针都使用了，在容器启动5秒后，kubelet将发送第一个readinessProbe探针，这将连接容器的8080端口，如果探测成功，则该pod为健康，十秒后，kubelet将进行第二次连接。
除了readinessProbe探针外，在容器启动15秒后，kubelet将发送第一个livenessProbe探针，仍然尝试连接容器的8080端口，如果连接失败，则重启容器。
探针探测的结果无外乎以下三者之一：
Success：Container通过了检查；
Failure：Container没有通过检查；
Unknown：没有执行检查，因此不采取任何措施（通常是我们没有定义探针检测，默认为成功）。
若觉得上面还不够透彻，可以移步其官网文档：https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/