简要说下Kubernetes有哪些核心组件以及这些组件负责什么工作？(8大组件)

etcd：提供数据库服务保存了整个集群的状态

kube-apiserver：提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制

kube-controller-manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等

cloud-controller-manager：是与底层云计算服务商交互的控制器

kub-scheduler：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上

kubelet：负责维护容器的生命周期，同时也负责Volume和网络的管理，运行在每个计算节点上，作为agent，接收分配该节点的Pods任务及管理容器，周期性获取容器状态，反馈给kube-apiserver。

kube-proxy：负责为Service提供内部的服务发现和负载均衡，并维护网络规则。运行在每个计算节点上，负责Pod网络代理。定时从etcd获取到service信息来做相应的策略。

container-runtime：是负责管理运行容器的软件，比如docker

kubectl:客户端命令行工具，作为整个系统的操作入口。

kube-controller-manager:执行整个系统的后台任务，包括节点状态状况、Pod个数、Pods和Service的关联等。

kube-scheduler:负责节点资源管理，接收来自kube-apiserver创建Pods任务，并分配到某个节点。

kube-dns：一个可选的DNS服务，用于为每个Service对象创建DNS记录，这样所有的Pod就可以通过DNS访问服务了。

Ingress Controller 为服务提供外网入口

Heapster 提供资源监控

Dashboard 提供 GUI

kubenetes针对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次。

参考：

https://zhuangxiaoyan.blog.csdn.net/article/details/120679513