07-Kubernetes冰山揭秘-第六层

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

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

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

监控底层基础设施

即使您正在将应用程序部署到Kubernetes集群中，您仍然需要关心承载该集群的底层基础结构。通常，这将是一组虚拟机或裸机主机。
您需要关心的度量标准与不使用Kubernetes时监视的度量标准相同：

• machine health
• CPU
• memory
• disk I/O

除此之外，您还可以添加Kubernetes和特定于容器的度量：

• CPU per container
• memory per container
• disk I/O per container
• number of running pods and pod state
• numbers of running nodes and their statuses

kube-state-metrics组件将向您提供许多特定于Kubernetes的度量标准。相比之下，非Kubernetes特定的必须由基础设施提供商提供。它可以是提供底层机器的云提供商，或者如果您运行的是用于管理机器的管理软件-Prem。
有关度量的更多信息和良好实践，您可以通过DataDog查看这篇伟大的文章。

Terraform-managed infrastructure

Terraform是一个开源的IaC工具。它允许您在文本文件中描述您的基础结构，并通过Terraform为您创建它。基础结构中的每个更改都要经过Terraform文件中的更改。
您可以使用Terraform在任何主要的云提供商（例如，AWS、Azure、GCP等）中通过该云的Terraform提供商提供Kubernetes集群。
您还可以使用Terraform来提供底层基础设施（虚拟机），并使用它来提升您自己的Kubernetes集群（例如，通过kubeadm）。
后者不太常见，因为如果您已经使用云提供商来管理您的基础设施，为什么不使用完整的包并让它管理您的Kubernetes集群。但是它有它的用例，例如，如果您正在运行多云，并且希望在多个云中提供VM，但然后以统一的方式在它们之上创建集群。

Cost analysis (cloud provider resources)

在当今世界，成本分析是一个重要的话题，我们的许多工作负载都运行在公有云（如AWS）中，在公有云中，我们是按小时计费的。
我们经常过度供应基础设施，并支付比我们使用的更多的费用。这有很多原因。如果你是一个资金充足的早期初创企业，你的主要目标是尽快建立一个好的产品，并达到产品与市场的匹配。在这种情况下，您通常不关心您的云提供商账单。另一个原因是，使用infra的人没有为此付费，所以当他们创建另一个Kubernetes集群或另一个虚拟机时，他们没有意识到（或不在乎）对公司的成本影响。此外，开发人员经常懒惰，忘记停止VM或向下扩展。
这就是为什么有很多公司专注于开发产品，帮助您测量云计算账单，并找到减少它的方法。
例如Kubecost、CloudZero和由您的云提供商（AWS Cost Explorer、Microsoft Cost Management、GCP Cost Management）提供的原生服务。

CNI (Cilium, Calico, flannel, integration with cloud provider VPCs)

CNI代表容器网络接口。CNI实现负责管理Kubernetes网络，例如，配置网络、提供IPs和维护主机之间的连接。
容器运行时与CNI通信，因此所有配置都是动态的，当POD被创建或删除时会发生变化。
一些CNI提供了额外的功能，如网络策略。
CNI有不同的实现方式。其中包括（但不限于）：

Cilium

Cilium是一个开源的CNCF孵化器项目，提供由EBPF支持的网络、安全性和可观测性。
它最初是由同价产生的。

Calico

Calico是一个由Tigera开发和维护的部分开源项目。
它支持Linux和Windows，也支持非Kubernetes工作负载。

flannel

Flannel是一个开源项目，提供第三层网络。
它通过在每个节点上部署flanneld守护进程并为节点分配子网来工作。

integration with cloud provider VPCs

当使用托管Kubernetes（例如，EKS、AKS、GKE等）时，您可以获得由云提供商为您管理的底层Kubernetes基础设施。您还可以为您管理Kubernetes（安装、升级等）。
云提供商可以为您管理的另一件事是网络端。云提供商允许您创建VPC-虚拟私有云。这些是完全封装的独立环境，您完全有能力定义VPC（或整个VPC）内部资源对外部世界的可见性级别。例如，您可以为您的测试环境创建一个VPC，它对外部世界完全隐藏，只能通过跳转框或VPN访问。这样，能够访问您的测试环境的人只有那些能够访问VPC的人，例如，您的开发人员，但是您将不会被泄露到外部世界或被搜索引擎索引。
同样的概念也可以应用于Kubernetes集群。云提供商允许您在自己的VPC中隔离一个集群，以便所有私有组件(etcd、api服务器）保持私有。一旦到了那里，您就可以采取步骤，通过一个位于VPC之外但可以访问它的网关显式地公开需要公开的部分（应用程序的入口）。
AWS还有一个CNI插件，其实现与VPC配置紧密耦合–https://github.com/AWS/amazon-vpc-cni-k8s

sysctl

sysctl是一个Linux实用程序，用于在运行时修改内核参数。
由于大多数Kubernetes集群运行在Linux节点上，所以可以在这些节点上使用sysctl。
可以从pod执行sysctl命令。在这种情况下，命令被分为2-safe和unsafe。安全命令只影响吊舱，不影响其他吊舱或节点。不安全的命令会影响其他吊舱和节点。
默认情况下，Kubernetes启用所有安全的sysctl命令，但不安全的命令需要由集群管理员专门启用。这是通过–Allowed-unsafe-sysctls kubelet标志完成的。
可以通过spec.securitycontext.sysctls参数配置Pod sysctl参数。例如，以下Pod规范将此Pod配置为sysctl参数kernel.shm_rmid_forced设置为0：

apiVersion: v1
kind: Pod
metadata:
  name: sysctl-example
spec:
  securityContext:
    sysctls:
      - name: kernel.shm_rmid_forced
        value: "0"

在这个场景中，Kubernetes没有区分安全和不安全的系统CTL，所以要小心设置。
如果要在节点上配置sysctls，则必须手动或运行特权守护集，为每个节点设置sysctl参数。

Control plane maintenance windows

当使用托管Kubernetes（例如EKS、AKS、GKE等）时，云提供商负责管理底层基础设施，集群本身包括版本升级。
如果您有一段时间没有升级集群，云提供商可以强制升级。例如，如果云提供商不再支持您正在运行的Kubernetes版本，则可能会发生这种情况，因此您需要转移到更新的版本。一些云提供商也支持自动升级到最新版本。
有时，云提供商允许您定义维护窗口，以便此更新不会破坏您的业务。例如，如果您是零售企业，则可能希望将此窗口设置为客户数量最少时。或者，如果您的客户位于欧洲，您可能希望将维护窗口放在欧洲的夜间，这样您的客户就不会受到影响。所有这些都是特定于业务的，但你明白了。
您可以查看AKS和GKE的维护windows文档。

Service Mesh (Istio)

服务网格是一个专用的基础结构层，可用于透明地向应用程序添加功能。其中包括监控、可观察性、TLS终止、认证/授权、负载平衡等。
这一层位于应用程序和客户之间。在Kubernetes中，它通常被实现为sidecar容器。这意味着Kubernetes将为您现有的每个容器创建一个额外的容器。这个容器将保存服务网格逻辑，并作为实际工作负载容器的入口和出口代理。这样，您就可以在那里实现TLS终止，并且您的应用程序将不必考虑TLS逻辑，但同时，您的系统将是TLS安全的。

Istio

Istio是服务网格的开源实现。它通过部署sidecar容器来工作。
它是由谷歌开发和维护的。
Istio服务网格的所有逻辑都是通过应用于集群的CRDs配置的。例如，这两个CRD为一个服务配置a/B测试，该服务有两个版本，版本之间的分发版本为60/40：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: test-vs
spec:
  gateways:
    - test-gateway
  hosts:
    - "*"
  http:
    - route:
        - destination:
            host: test-svc
            subset: "v1"
          weight: 60
        - destination:
            host: test-svc
            subset: "v2"
          weight: 40
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: test-destination-rule
spec:
  host: test
  subsets:
    - name: "v1"
      labels:
        version: "v1"
    - name: "v2"
      labels:
        version: "v2"

服务网格的另一个流行实现是Linkerd。

Network request tracing

在调试网络问题时，跟踪进出Kubernetes集群的网络请求是一件方便的事情。这可以通过几种方式实现。

Service meshes

一些服务网格为您提供了这样的跟踪功能。由于服务网格拦截所有进出吊舱的通信量，它们只需记录每个请求并向您提供这些信息，就可以轻松地做到这一点。

System traces

Kubernetes本机支持API服务器的请求跟踪。如果启用，它将为向API服务器发出的每个请求发出OpenTelemetry事件。
有关如何启用和使用它的更多信息，请查看文档。

Third-party product

许多安全产品也提供了某种跟踪功能。
这就是开源的SysDig Inspect，它与用于跟踪的kubectl插件相结合，允许您将跟踪添加到Kubernetes集群中。

Highly available control plane components

高可用控制平面意味着控制平面跨多个节点运行，每个控制平面组件至少复制在三个节点上。这样，即使一个节点失败，其他节点仍然可以提供功能，集群也不会停止运行。
这就是所有生产级集群的运行方式。只运行单个控制平面节点只是自找麻烦。您必须意识到基础结构可能并且将会使您失败，因此当发生这种情况时，您必须做好准备。
如果您正在运行托管Kubernetes（例如，EKS、AKS、GKE等），云提供商可能不允许您创建单个节点集群。如果您正在管理自己的集群，像kubeadm这样的工具可以为您提供设置高可用性集群的功能。

Certificate management in K8s control plane

大多数内部Kubernetes通信（集群组件之间的通信）都是通过HTTPS完成的。这意味着它需要CA证书。
默认情况下，Kubernetes将自动生成自签名证书，用于组件之间的通信。
您也可以使用自己的证书。这可以通过将API服务器配置为不生成证书，而是从磁盘上的某个位置获取证书来实现。像kubeadm这样的工具使这种配置变得容易。
您可以在本文中找到更多关于如何实现这一点的信息。
其他工具，如cert-manager，提供了与CA授权机构的集成，以便在旧证书过期时自动获取和生成新证书。

node-local-dns

NodeLocal DNS缓存是一种DNS缓存，旨在减少Pod查询控制平面节点以解析DNS的次数。使用NodeLocal DNS缓存（作为后台程序集在每个节点上运行），POD将查询缓存中的DNS记录，并仅在缓存丢失时调用API服务器。
有关如何配置它的更多信息，请查看此页。

Changes monitoring

如果希望持续监视Kubernetes资源的变化，可以通过提供–watch标志来使用kubectl。例如，kubectl get pods–watch将返回默认命名空间中的所有pod，但它将保持命令活动并继续轮询API服务器。每次创建或销毁一个新的pod时，它都会将其输出到控制台。
同样的行为可以通过Kubernetes Go库实现：

watch, err := client.Client.CoreV1().Pods("default").Watch(corev1.ListOptions{})
if err != nil {
  // handle error
}

for event := range watch.ResultChan() {
  // use event
}

这样，您就可以实现自定义仪表板，帮助您监视Kubernetes集群。

Operators

操作符是一个自定义的Kubernetes控制器，它与Kubernetes API交互，侦听给定对象的创建/更新/删除，并基于此事件触发一些逻辑。
它旨在通过提供一种实现自定义工作流的简单方法来简化自动化并允许Kubernetes的可扩展性。
通常，运算符绑定到自定义资源定义。操作员将监听自定义资源定义的创建/更新/删除，并在此事件发生时触发工作流。
操作符有许多用例，但供应是最常见的。假设我们希望编写一个操作符，在我们的Kubernetes集群中提供PostgreSQL数据库。首先，我们需要定义一个CRD。这个CRD将包含我们希望为我们提供的数据库的基本配置。一旦应用CRD，操作员将启动并向数据库提供指定的参数。这样，所有PostgreSQL特定于供应的逻辑都由操作员封装，作为用户，我们唯一关心的是指定所需的配置。

Configuring kubectl for Remote Access

kubectl是一个用于与Kubernetes交互的命令行工具。它将像kubectl get pods这样的CLI命令转换为对Kube API服务器的HTTP API调用（在本例中为get<api_server_addr>/API/v1/namespaces/default/pods)，并在终端中输出结果。
kubectl可用于联系任何Kubernetes集群-本地或远程。kubectl根据kubeconfig文件知道要联系哪个集群。kubeconfig文件是一个包含Kubernetes集群、它们的地址、证书等的YAML文件。要查看当前选定的集群，请使用kubectl config current-context命令。要查看当前kubeconfig文件中的所有集群，请使用kubectl config get-clusters命令。上下文是集群和用户之间的组合。对于同一个集群，可以有两个上下文，但用户不同。
您还可以使用–kubeconfig标志对不同的kubeconfig文件运行kubectl命令，如下所述

Non-destructive update applier

在我们创建了Kubernetes资源之后，我们经常发现需要更新它们。例如，在发布应用程序的新版本时更改部署的容器映像，重新配置服务等。
我们可以使用kubectl apply命令轻松地实现这一点。例如，我们可以通过kubectl apply-f deployment.yaml命令创建部署，然后通过更新文件并再次运行kubectl apply-f deployment.yaml来更新部署。
在计算新旧规范之间的差异时，Kubernetes使用策略合并补丁方法。这意味着Kubernetes试图做到非破坏性–在不删除任何旧属性的情况下添加新规范中添加的所有新属性。
这意味着如果要从对象中移除属性，必须在新规范中将它们显式设置为null，或者在数组的情况下，使用merge指令。