04-Kubernetes冰山揭秘-第四层

Kubernetes就像一座冰山。你学习了基础知识，却发现还有很多东西要学。你学得越多，你看到的就越多。这篇文章解释了Reddit上“Kubernetes冰山”模因中列出的所有概念。

不久前，u/dshurupov published a picture on Reddit上发布了一张我称之为“Kubernetes冰山”的照片。这张照片是由弗兰特的人制作的。

它代表了一座巨大的冰山，在上面你有一些最简单的Kubernetes概念，当你在下面和水下时，你会深入到更先进的Kubernetes主题。这是图片：

负载均衡

作为一个概念，负载平衡意味着您拥有给定工作负载的多个实例，但您不直接访问它们。相反，您访问一个负载均衡器/网关/反向代理，它决定调用工作负载的哪个实例。
在Kubernetes中，同样的概念可以应用于吊舱和服务。
在第1层中，我解释了服务如何为POD提供稳定的IP和网络，这些POD是短暂的，可以在任何给定的时间被其他POD（具有不同的IP）替换。
服务还提供这些吊舱之间的负载平衡。代表3个吊舱的服务将以循环的方式将流量路由到这些吊舱。

服务发现

服务发现是微服务体系结构中的服务相互发现的方式。
在Kubernetes之外，一个流行的服务发现工具是Eureka。它允许服务进行自我注册，并充当集中的服务注册中心。
Kubernetes以稍微不同的方式进行服务发现。
正如我们已经提到的，为工作负载提供稳定IPs的构造是服务。当您创建一个服务时，它将获得一个稳定的IP和一个在Kubernetes集群内有效的域名。在该集群中运行的所有工作负载都可以通过该服务的IP或域名访问该服务（及其背后的Pods）。

PID namespace sharing

当运行容器时，它们共享主机内核，但同时，它们通过cgroups和namespaces彼此隔离。PID命名空间意味着“进程ID命名空间”。每个容器都有自己的进程命名空间，这意味着一个容器看不到另一个容器运行的进程（即使它们运行在同一主机上）。
在一个Pod中运行多个容器时也是如此–它们在命名空间级别上是隔离的，并且看不到彼此的进程。
但是，Kubernetes使您能够使同一吊舱中的容器共享进程名称空间（因此能够看到彼此的进程）。
这可以通过将Pod spec-shareprocessnamespace中的一个简单标志设置为true来实现。
共享流程名称空间有几个用例。例如，如果您正在部署一个需要与主容器紧密集成的sidecar。或者，出于调试目的，您可以部署一个工作负载容器，该容器从所有调试工具中剥离出来，然后运行一个sidecar容器，该容器具有所需的所有实用工具，并使它们共享进程名称空间，以便您可以使用第二个容器来调试第一个容器。

硬驱逐和软驱逐

Kubernetes中的驱逐意味着kube-scheduler已经从节点中移除了一个豆荚。这可能是因为节点的CPU、磁盘或内存容量过大。
当启动kube-scheduler时，您可以配置硬驱逐阈值和软驱逐阈值，这将告诉Kubernetes在什么条件下执行驱逐。

软驱逐

软驱逐意味着Kubernetes将在终止豆荚之前给他们一些宽限期。该期间通过驱逐-soft-grace-period和驱逐-max-pod-grace-period标志进行配置。
通过evitication-soft属性配置执行软驱逐的条件。例如，memory.available<1.5GI值用于驱逐软配置，这意味着如果节点的可用内存低于1.5GB，Kubernetes将执行Pod的软驱逐。

硬驱逐

硬驱逐意味着Kubernetes将立即终止豆荚，没有任何宽限期。这是指在节点资源处于如此低的水平以至于必须立即执行某些操作的极端情况下发生的；否则，整个节点将失败。
执行硬驱逐的条件是通过驱逐-硬属性配置的。

Evictions API (PDB)

除了基于某些条件执行驱逐的kube-scheduler之外，您还可以通过调用Evictions API手动驱逐pod。
这样做就像将驱逐对象发送到Kube API服务器一样简单：

curl -v -H 'Content-type: application/json' https://<KUBE_API_SERVER>/api/v1/namespaces/default/pods/<POD_NAME>/eviction -d @eviction.json

其中evictions.json包含驱逐对象：

{
  "apiVersion": "policy/v1",
  "kind": "Eviction",
  "metadata": {
    "name": "<POD_NAME>",
    "namespace": "<NAMESPACE_NAME>"
  }
}

也可以通过Kubectl应用这个YAML对象：

kubectl apply -f eviction.yaml

其中Eviction.yaml包含驱逐对象：

apiVersion: policy/v1
kind: Eviction
metadata:
  name: <POD_NAME>
  namespace: <NAMESPACE_NAME>

另一种选择是使用kubectl drain命令，这将执行相同的操作，或者使用kubectl delete Pod<pod_name>-n<namespace_name>。
在所有这些示例中，<pod_name>表示要驱逐的Pod的名称，<namespace_name>是这个Pod所在的命名空间。
所有这些都将导致相同的事情：从节点中驱逐Pod。

Prometheus

Prometheus是一个开源的监视和警报工具包。它最初在SoundCloud中构建，现在隶属于CNCF（云原生计算基金会）。
它允许通过HTTP上的拉模型收集指标。
有各种适配器，允许您通过安装和配置适配器而无需做太多工作就可以收集不同类型的度量。还有各种编程语言的库，使您无需编写大量代码就可以在应用程序中收集自定义度量。
Prometheus已经成为度量集合的事实上的标准，您可以使用它来监视应用程序的运行、Kubernetes和Kubernetes集群本身。
为了可视化这些数据，您可以使用…

Grafana

Grafana是一个用于可视化数据的开源工具。它允许您为每一次度量构建一个自定义仪表板。
它支持来自多种来源的数据，包括Prometheus、MySQL、PostgreSQL等。
您可以自己部署和管理它，也可以使用Grafana在https://Grafana.com/提供的SaaS服务。

PromQL

PromQL代表普罗米修斯查询语言。它是一种结构化查询语言，允许您实时选择和聚合存储在Prometheus中的时间序列数据。
最简单的PQL表达式如下所示：

http_requests_total

该表达式将返回http_requests_total度量的所有时间序列数据。
如果希望按作业和处理程序标签进行筛选，可以像下面这样扩展查询：

http_requests_total{job="apiserver", handler="/api/comments"}

该语言支持许多复杂的表达式和函数，如rate、sum by等。
要获得完整的语言参考资料，请查看文档和示例。

健康检查

健康检查是一种操作，用于确定给定的Pod是否健康，是否可以为请求提供服务。
在创建Pod时，您可以定义“探测”，例如，Kubernetes将执行以确定应用程序状态的操作。
探针有三种类型：

启动探针

启动探测被定义为在应用程序启动时指示Kubernetes。
在启动探测成功执行之前，将禁用所有其他探测。
通过Pod规范中的spec.startupprobe字段定义。

存活探针

活性探针指示容器是否健康。如果没有，将重新启动。
通过Pod规范中的spec.livenessprobe字段配置活性探测。
有几种类型的活性探测–HTTP(LivenessProbe.httpget)、TCP(LivenessProbe.tcpsocket)、gRPC（LivenessProbe.gRPC）或命令（LivenessProbe.exec）。
Kubernetes将执行活性探测中定义的操作（例如，向端点发出HTTP GET请求），以确定应用程序是否健康。
如果连续几次活性探测失败，Kubernetes会认为豆荚不健康，并重新启动它。在Kubernetes失败之前，通过LivenessProbe.FailureThreshold字段配置失败所需的探测数。
这些探测还有其他细节，比如：

• 如果定义了启动探测，Kubernetes将等待它成功，然后开始尝试活性探测。否则，Kubernetes有可能重新启动甚至没有启动的豆荚，因为活性探测失败。
• 您还可以通过periodSeconds属性配置Kubernetes检查活性探测的频率。
• 您可以通过initialDelaySeconds属性配置容器开始等待多长时间才能调用探测。

就绪探针

类似于活性探测，但显示Pod是否准备好为请求服务。
如果活性探测失败，将重新启动吊舱。如果就绪探测失败，则Pod将不会重新启动，而是从服务负载均衡器中移除（这样它就不会为请求服务）。
通过Pod规范中的spec.readinessProbe字段定义。
活性探测的所有配置选项对于就绪探测也是有效的。

Terraform

Terraform是一个开源工具，它允许您在Terraform文件中描述您的基础结构，并通过一个简单的命令创建/更新它。这就是所谓的IaC或基础设施作为代码。
它通过所谓的Terraform提供商支持多个云提供商。例如，您可以将AWS提供程序用于AWS资源，将Azure提供程序用于Azure资源，等等。
通过这样做，您可以通过GitOps方法以集中的方式管理您的基础结构。您可以将Terraform文件保存在git Repo中。每次有人想要对您的基础结构进行更改（例如，创建一个新的Kubernetes集群或一个新的虚拟机），他们都需要对Terraform文件进行更改，提交该文件，并打开一个Pull Requests，对其进行审查和批准，然后将其合并。一旦合并，CI/CD管道将负责运行创建新资源的Terraform命令。
如果不使用这样的解决方案，就意味着有人需要手动使用云提供商UI来创建新的资源。这有很多缺点。例如：

• 您必须为您所拥有的每个环境执行一次此操作。例如，如果您有dev、test和prod环境，则必须执行三次此操作，每个环境一次。使用Terraform，您可以在一个环境中重用一组文件。
• 这样做的人不能以简单的方式让团队成员验证他的工作。例如，你如何确保这样做的人会创建正确的资源？使用Terraform和GitOps，在合并到主分支并应用之前，对所有更改进行审查。
• 没有Terraform，您就无法简单地跟踪所有基础设施。如果您有三个环境，但想创建第四个环境，这可能是一个问题。如何确保没有错过在新环境中创建一些资源？你不能。Terraform不会有这个问题，因为您的整个环境都在Terraform文件中进行了描述。

其他IaC项目提供了Terraform的替代品。这些包括但不限于Pulumi、AWS云结构（仅针对AWS资源）、Azure资源模板（仅针对Azure资源）等。

QoS (cgroups, oom_score_adj)

QoS代表服务质量。
在Kubernetes中，QoS类是Kubernetes将根据资源限制配置分配给您的豆荚的属性。
QoS类是：

Guaranteed

保证QoS类被分配给满足以下条件的吊舱：

• 吊舱中的每个容器都有一个内存限制和一个内存请求
• 对于吊舱中的每个容器，内存限制等于内存请求。
• 吊舱中的每个容器都有一个CPU限制和一个CPU请求。
• 对于吊舱中的每个容器，CPU限制等于CPU请求。

Burstable

Burstable QoS类被分配给不满足保证条件但满足以下条件的吊舱：

• 所述吊舱中的至少一个容器具有内存或CPU请求或限制

BestEffort

BestEffort QoS类被分配给容器没有任何内存或CPU限制或请求的吊舱。

HPA/VPA based on custom metrics

在上一篇文章中，我解释了什么是HPA以及如何使用Kubernetes定义的度量来实现HPA。
您可以做的另一件事是定义您的自定义指标，HPA可以使用该指标来确定何时扩展/扩展。
这是由像metrics-server这样的工具启用的，这些工具向metrics API公开自定义度量。然后，HPA（配置为查看它们）使用这些度量来确定工作负载是否需要伸缩。
除了我们在上一篇文章中谈到的HorizontalPodAutoscaler之外，还有垂直Pod AutoScaler。垂直伸缩意味着，我们不是创建新的工作负载实例，而是增加现有负载的资源（例如，我们提供更多的内存、CPU和磁盘）。
使用VPA，您不需要为您的工作负载设置资源限制，相反，VPA将设置它们并相应地调整它们。
VPA还支持自定义度量。