【微服务】Kubernetes对象之Nodes和 Master与Node的通信

 

Kubernetes Nodes：

Node是Kubernetes中的工作节点，最开始被称为minion。
一个Node可以是VM或物理机。
每个Node（节点）具有运行pod的一些必要服务，并由Master组件进行管理。
Node节点上的服务包括Docker、kubelet和kube-proxy。
 

Node Status：

节点的状态信息包含：

• Addresses
• Condition
• Capacity
• Info
   

Addresses：

这些字段的使用取决于云提供商或裸机配置。

• HostName：可以通过kubelet 中 --hostname-override参数覆盖。
• ExternalIP：可以被集群外部路由到的IP。
• InternalIP：只能在集群内进行路由的节点的IP地址。
   

Condition：

node condition被表示为一个JSON对象。
conditions字段描述所有Running节点的状态。
OutOfDisk True：如果节点上没有足够的可用空间来添加新的pod；否则为：False
Ready True：如果节点是健康的并准备好接收pod；
False：如果节点不健康并且不接受pod；
Unknown：如果节点控制器在过去40秒内没有收到node的状态报告。
MemoryPressure True：如果节点存储器上内存过低; 否则为：False。
DiskPressure True：如果磁盘容量存在压力 - 也就是说磁盘容量低；否则为：False。
 

Capacity：

描述节点上可用的资源：CPU、内存和可以调度到节点上的最大pod数。
 

Info：

关于节点的一些基础信息，如内核版本、Kubernetes版本（kubelet和kube-proxy版本）、Docker版本（如果有使用）、OS名称等。
 

Management：

节点不是由Kubernetes 系统创建，它是由Google Compute Engine等云提供商在外部创建的，或使用物理和虚拟机。
当Kubernetes创建一个节点时，它只是创建一个代表节点的对象，创建后，Kubernetes将检查节点是否有效。
Kubernetes将保留无效节点的对象（除非客户端有明确删除它）并且它将继续检查它是否变为有效。
有三个组件与Kubernetes节点接口进行交互：节点控制器（node controller）、kubelet和kubectl。
 

Node Controller：

节点控制器（Node Controller）是管理节点的Kubernetes master组件。
节点控制器在节点的生命周期中具有多个角色。
第一个是在注册时将CIDR块分配给节点。
第二个是使节点控制器的内部列表与云提供商的可用机器列表保持最新。
第三是监测节点的健康状况。
节点控制器还负责驱逐在节点上运行的NoExecutepod。
 

Self-Registration of Nodes：

当kubelet flag --register-node为true（默认值）时，kubelet将向API服务器注册自身。
对于self-registration，kubelet从以下选项开始：
--api-servers - apiservers的位置。
--kubeconfig - 路径到凭证，以验证其自身到apiserver。
--cloud-provider - 如何与云提供商对话来读取关于自身的元数据。
--register-node - 自动注册到API服务器。
--register-with-taints - 在给定的目录列表中注册节点(逗号分隔<key>=<value>:<effect>)。如果register-node是false，则禁止操作。
--node-ip IP 地址的节点。
--node-labels - 在集群中注册节点时添加标签。
--node-status-update-frequency - 指定kubelet的节点状态为master的频率。
 

手动管理节点：

集群管理员可以创建和修改节点对象。
如果管理员希望手动创建节点对象，请设置kubelet flag  --register-node=false。
管理员可以修改节点资源（不管--register-node设置如何），修改包括在节点上设置的labels 标签，并将其标记为不可调度的。
节点上的标签可以与pod上的节点选择器一起使用，以控制调度。
将节点标记为不可调度将防止新的pod被调度到该节点，但不会影响节点上的任何现有的pod，这在节点重新启动之前是有用的。
由daemonSet控制器创建的pod可以绕过Kubernetes调度程序，并且不遵循节点上无法调度的属性。
 

Node容量：

节点的容量(cpu数量和内存数量)是节点对象的一部分。
节点在创建节点对象时注册并通知其容量。
如果是手动管理节点，则需要在添加节点时设置节点容量。
Kubernetes调度程序可确保节点上的所有pod都有足够的资源。
它会检查节点上容器的请求的总和不大于节点容量。
 

API 对象：

Node是Kubernetes REST API中的最高级别资源。




 

Kubernetes Master-Node通信：

Cluster -> Master：
从集群到Master节点的所有通信路径都在apiserver中终止。
一个典型的deployment ，如果apiserver配置为监听进程连接上的HTTPS 443端口，应启用一种或多种client authentication，特别是如果允许anonymous requests或service account tokens 。
Node节点应该配置为集群的公共根证书，以便安全地连接到apiserver。
希望连接到apiserver的Pod可以通过service account来实现，以便Kubernetes在实例化时自动将公共根证书和有效的bearer token插入到pod中。
kubernetes service (在所有namespaces中)都配置了一个虚拟IP地址，该IP地址由apiserver重定向(通过kube - proxy)到HTTPS。
Master组件通过非加密(未加密或认证)端口与集群apiserver通信。
这个端口通常只在Master主机的localhost接口上暴露。


Master -> Cluster：
从Master (apiserver)到集群有两个主要的通信路径。
第一个是从apiserver到在集群中的每个节点上运行的kubelet进程。
第二个是通过apiserver的代理功能从apiserver到任何node、pod或service 。


apiserver - > kubelet：
从apiserver到kubelet的连接用于获取pod的日志，通过kubectl来运行pod，并使用kubelet的端口转发功能。
默认情况下，apiserver不会验证kubelet的服务证书，这会使连接不受到保护。
要验证此连接，使用--kubelet-certificate-authority flag为apiserver提供根证书包，以验证kubelet的服务证书。
应该启用Kubelet认证或授权来保护Kubelet API。


apiserver -> nodes、pods、services：
从apiserver到Node、Pod或Service的连接默认为HTTP连接，因此不需进行认证加密。
这些连接不可以在不受信任/或公共网络上运行。

 

SSH Tunnels：

Google Container Engine 使用SSH tunnels来保护 Master -> 集群 通信路径

 

SSH tunnel能够使Node、Pod或Service发送的流量不会暴露在集群外部。

 

 

内容整理自Kubernetes中文社区：https://www.kubernetes.org.cn/