Kubernetes 引导启动

Kubernetes 引导启动

这是使用kops时,关于Kubernetes集群是如何建立启动的概述。

从spec 到完整配置

kops工具本身采用用户指定的集群的(最小)规范,并计算完整配置,设置未指定值的默认值,并导出适当的依赖关系。 “完整”规范包含将传递给所有组件的所有标志集。 所有关于如何安装集群的决定都是在这个阶段做出的,因此如果用户在规范中指定了一个值,理论上可以改变每一个决定。

此完整规范在AutoScaling组(在AWS上)或Managed Instance Group(在GCE上)的启动配置中设置。

在AWS和GCE上,一切(nodes & masters)都在ASG / MIG中运行; 这意味着失败(或用户)可以终止机器并且kops系统将会进行自我修复。

nodeup:从image到kubelet

nodeup是为Kubelet安装软件包并设置操作系统的组件。 核心要求是:

  • 必须安装Docker。 nodeup将安装Docker 1.13.1,这是Docker与Kubernetes 1.8一起测试的版本。
  • Kubelet,并且安装了systemd服务。

另外,nodeup还会安装:

  • Protokube,这是一个kops专用组件

/etc/kubernetes/manifests

由/etc/kubernetes/manifest 中的文件控制kubelet启动pods。这些文件由nodeup和protokube(理想情况下全部由protokube创建,但目前是由两者分开的)创建。

这些pod使用标准k8s manifests声明,就像它们存储在API中一样。 但是它们被用来打破我们核心组件的循环依赖,比如etcd和kube-apiserver。

在master上:

  • kube-apiserver
  • kube-controller-manager (运行各种控制器)
  • kube-scheduler (它将pod分配给node)
  • etcd (这实际上是由protokube创建的)
  • dns-controller

在node上:

  • 配置iptables使k8s网络工作

kubelet start

Kubelet启动/重启)/etc/kubernetes/manifest 中的所有容器。

Kubelet还尝试联系API server(master kubelet本身最终会启动),注册该节点。一旦节点注册完成,kube-controller-manager将为其分配一个PodCIDR,它是分配范围在k8s网络IP内。 kube-controller-manager更新节点,设置PodCIDR字段。 一旦kubelet看到这个分配,它将用这个CIDR建立本地网桥,允许docker启动。在这之前,只有具有hostNetwork的pod才能工作 - 因此所有“核心”容器都以hostNetwork=true运行。

api-server启动

api-server将在主服务器上监听localhost:8080。 这是一个不安全的端点,但只能从主服务器访问,并且仅适用于使用hostNetwork = true运行的Pod。 这就是像kube-scheduler和kube-controller-manager这样的组件可以在不需要令牌的情况下到达API。