【 k8s 概念（九）】Kubernetes Nodes

本文主要是介绍【 k8s 概念（九）】Kubernetes Nodes，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

文章目录

• • Node是什么？
  • Node Status
  • • Addresses
    • Condition
    • Capacity
    • Info
  • Management
  • Node Controller
  • Kubernetes Master-Node通信
  • • Cluster -> Master
    • Master -> Cluster
    • • apiserver - > kubelet
      • apiserver -> nodes、pods、services
      • SSH Tunnels

Node是什么？

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

Node Status

Addresses

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

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

Condition

conditions字段描述所有Running节点的状态。

Capacity

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

Info

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

Management

与 pods 和 services 不同，节点不是由Kubernetes 系统创建，它是由Google Compute Engine等云提供商在外部创建的，或使用物理和虚拟机。这意味着当Kubernetes创建一个节点时，它只是创建一个代表节点的对象，创建后，Kubernetes将检查节点是否有效。

请注意，Kubernetes将保留无效节点的对象（除非客户端有明确删除它）并且它将继续检查它是否变为有效。

Node Controller

节点控制器（Node Controller）是管理节点的Kubernetes master组件。

节点控制器在节点的生命周期中具有多个角色。第一个是在注册时将CIDR块分配给节点。

第二个是使节点控制器的内部列表与云提供商的可用机器列表保持最新。当在云环境中运行时，每当节点不健康时，节点控制器将询问云提供程序是否该节点的VM仍然可用，如果不可用，节点控制器会从其节点列表中删除该节点。

第三是监测节点的健康状况。当节点变为不可访问时，节点控制器负责将NodeStatus的NodeReady条件更新为ConditionUnknown，随后从节点中卸载所有pod ，如果节点继续无法访问，（默认超时时间为40 --node-monitor-period秒，开始报告ConditionUnknown，之后为5m开始卸载）。节点控制器按每秒来检查每个节点的状态。

在大多数情况下，节点控制器将逐出速率限制为 --node-eviction-rate（默认为0.1）/秒，这意味着它不会每10秒从多于1个节点驱逐Pod。

当给定可用性的区域中的节点变得不健康时，节点逐出行为发生变化，节点控制器同时检查区域中节点的不健康百分比（NodeReady条件为ConditionUnknown或ConditionFalse）。如果不健康节点的比例为 --unhealthy-zone-threshold（默认为0.55），那么驱逐速度就会降低：如果集群很小（即小于或等于–large-cluster-size-threshold节点 - 默认值为50），则停止驱逐，否则， --secondary-node-eviction-rate（默认为0.01）每秒。这些策略在可用性区域内实现的原因是，一个可用性区域可能会从主分区中被分区，而其他可用区域则保持连接。如果集群没有跨多个云提供商可用性区域，那么只有一个可用区域(整个集群)。

在可用区域之间传播节点的一个主要原因是，当整个区域停止时，工作负载可以转移到健康区域。因此，如果区域中的所有节点都不健康，则节点控制器以正常速率逐出–node-eviction-rate。如所有的区域都是完全不健康的（即群集中没有健康的节点），在这种情况下，节点控制器会假设主连接有一些问题，并停止所有驱逐，直到某些连接恢复。

从Kubernetes 1.6开始，节点控制器还负责驱逐在节点上运行的NoExecutepod。

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的端口转发功能。这些连接在kubelet的HTTPS终端处终止。

默认情况下，apiserver不会验证kubelet的服务证书，这会使连接不受到保护。

要验证此连接，使用–kubelet-certificate-authority flag为apiserver提供根证书包，以验证kubelet的服务证书。

如果不能实现，那么请在apiserver和kubelet之间使用 SSH tunneling。

最后，应该启用Kubelet认证或授权来保护Kubelet API。

apiserver -> nodes、pods、services

从apiserver到Node、Pod或Service的连接默认为HTTP连接，因此不需进行认证加密。也可以通过HTTPS的安全连接，但是它们不会验证HTTPS 端口提供的证书，也不提供客户端凭据，因此连接将被加密但不会提供任何诚信的保证。这些连接不可以在不受信任/或公共网络上运行。

SSH Tunnels

Google Container Engine 使用SSH tunnels来保护 Master -> 集群 通信路径，SSH tunnel能够使Node、Pod或Service发送的流量不会暴露在集群外部。
K8S中文社区微信公众号

这篇关于【 k8s 概念（九）】Kubernetes Nodes的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！