讲解各个核心组件之前，我们先看一下之前画的k8s整体的架构图回忆一下各个组件之间如何协同工作的。

一、核心组件整体总览

（一）kubectl

跟k8s集群打交道的客户端，我们常用的命令就是通过kubectl来执行的。

（二）API Server

k8s集群的中枢纽带，负责多方面的事情：
（1）yml文件在/etc/kubernetes/manifests/kube-apiserver.yaml下，是kubelet管理的静态pod
（2）–insecure-port=0代表使用http非安全协议访问
（3）安全验证一些文件
（4）准入策略的拦截器
（5）–authorization-mode=Node,RBAC，限制kubelet的权限
（6）)–etcd，配置apiserver与etcd通信

（三）Scheduler

单纯地调度pod，按照特定的调度算法和策略，将待调度pod绑定到集群中某个适合的Node，并写入绑定信息，由对应节点的kubelet服务创建pod。
（1）yml文件在/etc/kubernetes/manifests/kube-scheduler.yaml下，是kubelet管理的静态pod
（2）–address表示只在master节点上提供服务，不对外

（四）Controller Manager

负责管理集群中的Node、Pod副本、服务的endpoint、命名空间、ServiceAccount、资源配合等内容；
会划分成不同类型的controller，每个controller都是一个死循环，再循环中controller通过API Server监视自己控制资源的状态，一旦状态发生变化就会努力改变状态，直到变成期望的状态。
（1）yml文件在/etc/kubernetes/manifests/kube-controller-manager.yaml下，是kubelet管理的静态pod
（2）多个manager需要进行leader选举

（五）kubelet

集群中的所有节点都有运行，用于管理pod和container，每个kubelet会向apiserver注册本节点的信息，并向master节点上报本节点资源使用情况。
kubelet由操作系统init进行启动，可以使用如下命令进入目录查看以及启动：

ls /lib/systemd/system/kubelet.service
systemctl daemon-reload & systemctl restart kubelet

（六）kube-proxy

集群中的所有节点都有运行kube-proxy，像service的操作都是由kube-proxy代理的，对于客户端来说是透明的。

（1）kube-proxy由daemonset控制器在各个节点上启动唯一实例；
（2）配置参数：/var/lib/kube-proxy/config.conf(pod内)，不是静态pod

可以使用一下命令进入配置文件：

kubectl get pods -n kube-system
kubectl exec kube-proxy-jt9n4 -n kube-system -- cat /var/lib/kube-proxy/config.conf

（七）DNS

域名解析

（八）dashboard

控制面板，可视化的的页面能够监控整个集群的状态，但是监控的不够全。

（九）etcd

整个集群的配置中心，集群所有的状态数据，对象数据都存储在etcd中。
kubeadm引导启动的k8s集群默认只启动一个etcd节点
（1）etcd的yml文件在/etc/kubernetes/manifests/etcd.yaml下，是kubelet管理的静态pod
（2）etcd所使用的相关秘钥在/etc/kubernetes/pki/etcd下
（3）etcd挂载master节点本地路径/var/lib/etcd用于运行时数据存储

二、Kubernetes源码

源码地址：https://github.com/kubernetes/kubernetes

三、节点

官网：https://kubernetes.io/zh/docs/concepts/architecture/nodes/

可以使用一下命令查看集群中的节点：

kubectl get nodes
kebectl describe node nodeName

四、kubeadm

（一）kubeadm init

1、init之前进行一系列检查确定这台机器可以部署k8s集群，版本之间是否兼容、各种端口的占用情况等；
2、生成kubernetes对外提供服务所需要的各种证书可对应目录，也就是生成私钥和数字证书，一般都是在/etc/kubernetes/pki/*下；
3、为其他组件生成访问api server所需的配置文件，xxx.conf；
4、为master生成pod配置文件，这些组件会被master节点上的kubelet读取到，并且创建对应资源，一般都是一些静态pod，直接使用主机网络；
5、下载镜像，等待控制平面启动；
6、一旦yaml文件出现在被kubelet监视的/etc/kubernetes/manifests/目录下，kubelet就会自动创建这些yml文件定义的pod，即master组件的容器。master容器启动后，kubeadm会通过检查localhost:6443/health这个组件的健康状态检查url,等待master组件完全运行起来；
7、为集群生成一个bootstrap token，设定当前node节点为master节点，master节点将不承担工作负载；
8、将ca.crt等master节点的重要信息，通过configMap的方式保存在etcd中，后续部署node节点使用；
9、安装默认插件，kubernetes默认kube-proxy和DNS是必须安装的，dns插件安装了会出于pending状态，要等网络插件安装完成，例如calico

（二）kubeadm join

kubeadm join 192.168.0.xx:6443 --token yu1ak0.2dcecvmpozsy8loh \ --discovery-token-ca-cert-hash sha256:5c4a69b3bb05b81b675db5559b0e4d7972f1d0a61195f217161522f464c307b0

1、join前检查；
2、discovery-token-ca-cert-hash用于验证master身份
3、token用于master验证node
#在master上节点上，可以查看对应的token

kubectl get secret -n kube-system | grep bootstrap-token 

#得到token的值

kubectl get secret/bootstrap-token-kggzhc -n kube-system -o yaml 

#对token的值进行解码

echo NHRzZHp0Y2RidDRmd2U5dw==|base64 -d --->4tsdztcdbt4fwe9w

#最终token的值

kggzhc.4tsdztcdbt4fwe9w

4、实在忘了怎么办？
有些小伙伴可能没有及时保存最后的join信息，或者24小时之后过期了，这时候可以重新生成
4.1、重新生成token
kubeadm token create
4.2、获取ca证书sha256编码hash值
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed ‘s/^.* //’
4.3、重新生成join信息
kubeadm join 主节点ip地址:6443 --token token填这里 --discovery-token-ca-cert-hash sha256:哈希值填这里

五、kubectl

官网：https://kubernetes.io/docs/reference/kubectl/overview/
语法：kubectl [command] [TYPE] [NAME] [flags]

command：指定对一个或者多个资源的操作，例如get、describe、apply等；
TYPE：指定资源类型。资源类型不区分大小写， 可以指定单数、复数或缩写形式。例如pod，也可以使用pods或者po。
NAME：指定资源的名称。名称区分大小写。 如果省略名称，则显示该资源类型所有资源的详细信息（默认命名空间下的）。
flags：指定可选的参数。例如，可以使用 -s 或 -server 参数指定 Kubernetes API 服务器的地址和端口。

六、API Server

官网：https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-apiserver/

API Server提供了对k8s集群内资源的操作，例如pod，services等，它是整个集群内各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。通常我们通过kubectl与API Server进行交互。

API Server通过kube-apiserver的进程提供服务，运行在master节点上，kubectl与API Server之间是REST调用。

七、集群安全机制之API Server

官网：https://kubernetes.io/docs/concepts/security/controlling-access/
对k8s集群来讲，每次外界跟k8s集群交互都是通过API Server的rest api实现的，但是并不是都能随意访问k8s集群的，其中还涉及了授权、认证、准入等操作，其中最主要的是认证、授权、准入控制。

（一）认证（Authentication）

官网：https://kubernetes.io/docs/concepts/security/controlling-access/#authentication

可以看到认证是客户端跟k8s集群打交道的第一步，通过了这一步才能继续往下走。认证说白了就是识别客户端的身份，k8s集群提供了多种识别客户端身份的方式：
客户端证书、密码、普通令牌、引导令牌和 JSON Web 令牌。

可以设置一个，也可以设置多个认证方式，只要有一个通过认证即可。

（二）授权（Authorization）

官网：https://kubernetes.io/docs/concepts/security/controlling-access/#authorization
授权大致原理就是跟普通的管理系统一样，不同的角色有不同的权限，而不同的用户有不同的角色，能通过角色来控制用户能看到的权限。

授权官网提供了多种模式，例如ABAC授权模式、RBRC授权模式、Webhook授权模式。

如上图，用户绑定一个RoleBindingClusterRoleBinding，然后RoleBindingClusterRoleBinding再绑定RoleClusterRole，RoleClusterRole对应不同的权限。

（三）准入控制（Admission Control）

官网：https://kubernetes.io/docs/concepts/security/controlling-access/#admission-control

准入控制有多种控制策略，不同的策略代表着对请求的不同处理，即使前面的两道步骤都通过了，但是准入策略配置了拒绝该请求也是会被立马拒绝。以下是最常用的三种策略：

Always：允许所有的请求
AlwaysPullmages：在启动容器之前总是尝试重新下载镜像
AlwaysDeny：禁止所有请求

八、Scheduler

官网：https://kubernetes.io/docs/concepts/scheduling/kube-scheduler/

通过调度算法，为待调度的Pod选择最适合的Node节点，然后目标节点上kubelet通过API Server监听到Kubernetes Scheduler产生的Pod绑定事件，获取对应的Pod清单，下载image镜像并启动容器。

（一）整体架构图

调度流程可以在Scheduler官网看，我这里大致描述一下：
流程大致分为两步，首先是过滤（Filtering），然后是打分（Scoring）。
先过滤出满足条件的Node节点，一般满足条件的是多个，如果过滤后的结果为0个，那么代表当前Pod无节点可用。然后对满足条件的Node节点根据打分规则进行打分，最后会将Pod调度到分数最高的Node节点上，如果分数最高的节点有多个，那么会随即选择一个节点。

（二）调度策略和调度配置

Scheduler支持两种方式配置调度器的过滤和打分规则：
调度策略：可以配置过滤条件（Predicates）进行过滤，配置优先级（Priorities）进行打分；
调度配置：可以配置实现不同调度阶段的插件。你也可以配置Scheduler运行不同的配置文件。

2.1、调度策略

官网：https://kubernetes.io/docs/reference/scheduling/policies/
官网提供了不同类型的Predicates和Priorities供使用：

2.2、调度配置

官网：https://kubernetes.io/docs/reference/scheduling/config/
官方提供了不同的扩展插件：

九、kubelet

官网：https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/
在k8s集群中，每个Node上都有一个kubelet服务进程，用于处理master节点下发到本节点的任务。
管理Pod以及Pod中的容器，每个kubelet进程会在API Server上注册自身节点信息，定期向master节点汇报节点资源的使用情况，并通过cAvisor监控容器和节点资源。

十、kube-proxy

官网：https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/
在k8s集群中，每个Node节点上都会运行一个kube-proxy，它是Service的透明代理兼负载均衡器，核心功能是将某个Service的访问请求转发到后端的多个Pod实例上。