Kubernetes是啥？

Posted 2023-03-29

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Kubernetes是啥？相关的知识，希望对你有一定的参考价值。

Kubernetes是什么？

首先，它是一个全新的基于容器技术的分布式架构领先方案。这个方案虽然还很新，但它是谷歌十几年以来大规模应用容器技术的经验积累和升华的重要成果。确切地说，Kubernetes是谷歌严格保密十几年的秘密武器——Borg的一个开源版本。Borg是谷歌的一个久负盛名的内部使用的大规模集群管理系统，它基于容器技术，目的是实现资源管理的自动化，以及跨多个数据中心的资源利用率的最大化。十几年以来，谷歌一直通过Borg系统管理着数量庞大的应用程序集群。由于谷歌员工都签署了保密协议，即便离职也不能泄露Borg的内部设计，所以外界一直无法了解关于它的更多信息。直到2015年4月，传闻许久的Borg论文伴随Kubernetes的高调宣传被谷歌首次公开，大家才得以了解它的更多内幕。正是由于站在Borg这个前辈的肩膀上，汲取了Borg过去十年间的经验与教训，所以Kubernetes一经开源就一鸣惊人，并迅速称霸容器领域。其次，如果我们的系统设计遵循了Kubernetes的设计思想，那么传统系统架构中那些和业务没有多大关系的底层代码或功能模块，都可以立刻从我们的视线中消失，我们不必再费心于负载均衡器的选型和部署实施问题，不必再考虑引入或自己开发一个复杂的服务治理框架，不必再头疼于服务监控和故障处理模块的开发。总之，使用Kubernetes提供的解决方案，我们不仅节省了不少于30%的开发成本，还可以将精力更加集中于业务本身，而且由于Kubernetes提供了强大的自动化机制，所以系统后期的运维难度和运维成本大幅度降低。

然后，Kubernetes是一个开放的开发平台。与J2EE不同，它不局限于任何一种语言，没有限定任何编程接口，所以不论是用Java、Go、C++还是用Python编写的服务，都可以被映射为Kubernetes的Service（服务），并通过标准的TCP通信协议进行交互。此外，Kubernetes平台对现有的编程语言、编程框架、中间件没有任何侵入性，因此现有的系统也很容易改造升级并迁移到Kubernetes平台上。

最后，Kubernetes是一个完备的分布式系统支撑平台。Kubernetes具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建的智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。同时，Kubernetes提供了完善的管理工具，这些工具涵盖了包括开发、部署测试、运维监控在内的各个环节。因此，Kubernetes是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式的完备的分布式系统开发和支撑平台。

在正式开始本章的Hello World之旅之前，我们首先要学习Kubernetes的一些基本知识，这样才能理解Kubernetes提供的解决方案。

在Kubernetes中，Service是分布式集群架构的核心，一个Service对象拥有如下关键特征。

拥有唯一指定的名称（比如mysql-server）。

拥有一个虚拟IP（Cluster IP、Service IP或VIP）和端口号。

能够提供某种远程服务能力。

被映射到提供这种服务能力的一组容器应用上。

Service的服务进程目前都基于Socket通信方式对外提供服务，比如Redis、Memcache、MySQL、

Web Server，或者是实现了某个具体业务的特定TCP Server进程。虽然一个Service通常由多个相关的服务进程提供服务，每个服务进程都有一个独立的Endpoint（IP+Port）访问点，但Kubernetes能够让我们通过Service（虚拟Cluster IP +Service Port）连接到指定的Service。有了Kubernetes内建的透明负载均衡和故障恢复机制，不管后端有多少服务进程，也不管某个服务进程是否由于发生故障而被重新部署到其他机器，都不会影响对服务的正常调用。更重要的是，这个Service本身一旦创建就不再变化，这意味着我们再也不用为Kubernetes集群中服务的IP地址变来变去的问题而头疼了。

容器提供了强大的隔离功能，所以有必要把为Service提供服务的这组进程放入容器中进行隔离。为此，Kubernetes设计了Pod对象，将每个服务进程都包装到相应的Pod中，使其成为在Pod中运行的一个容器（Container）。为了建立Service和Pod间的关联关系，Kubernetes首先给每个Pod都贴上一个标签（Label），给运行MySQL的Pod贴上name=mysql标签，给运行php的Pod贴上name=php标签，然后给相应的Service定义标签选择器（Label Selector），比如MySQL Service的标签选择器的选择条件为name=mysql，意为该Service要作用于所有包含name=mysql Label的Pod。这样一来，就巧妙解决了Service与Pod的关联问题。

这里先简单介绍Pod的概念。首先，Pod运行在一个被称为节点（Node）的环境中，这个节点既可以是物理机，也可以是私有云或者公有云中的一个虚拟机，通常在一个节点上运行几百个Pod；其次，在每个Pod中都运行着一个特殊的被称为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此它们之间的通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中；最后，需要注意的是，并不是每个Pod和它里面运行的容器都能被映射到一个Service上，只有提供服务（无论是对内还是对外）的那组Pod才会被映射为一个服务。

在集群管理方面，Kubernetes将集群中的机器划分为一个Master和一些Node。在Master上运行着集群管理相关的一组进程kube-apiserver 、 kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且都是自动完成的。Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。在Node上运行着Kubernetes的kubelet、kube-proxy服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁，以及实现软件模式的负载均衡器。

最后，看看传统的IT系统中服务扩容和服务升级这两个难题，以及Kubernetes所提供的全新解决思路。服务的扩容涉及资源分配（选择哪个节点进行扩容）、实例部署和启动等环节，在一个复杂的业务系统中，这两个难题基本上靠人工一步步操作才得以解决，费时费力又难以保证实施质量。

在Kubernetes集群中，只需为需要扩容的Service关联的Pod创建一个RC（Replication Controller），服务扩容以至服务升级等令人头疼的问题都迎刃而解。在一个RC定义文件中包括以下3个关键信息。

目标Pod的定义。

目标Pod需要运行的副本数量（Replicas）。

要监控的目标Pod的标签。

在创建好RC（系统将自动创建好Pod）后，Kubernetes会通过在RC中定义的LabelPod实例并实时监控其状态和数量，如果实例数量少于定义的副本数量，则会根据在RC中定义的Pod模板创建一个新的Pod，然后将此Pod调度到合适的Node上启动运行，直到Pod实例的数量达到预定目标。这个过程完全是自动化的，无须人工干预。有了RC，服务扩容就变成一个纯粹的简单数字游戏了，只需修改RC中的副本数量即可。后续的服务升级也将通过修改RC来自动完成。参考技术A Kubernetes（K8s）是一款由谷歌开源的容器集群管理系统。它基于容器技术，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列功能。
如今，Kubernetes 和更广泛的容器生态系统正在逐渐成熟，形成一个通用的计算平台和生态系统 - 虚拟机 (VM) 是现代云基础架构和应用的基础构建块，它即使没有超越虚拟机，也可以与之抗衡。此生态系统使组织能够提供高生产力的平台即服务 (PaaS)，解决围绕云原生开发、与基础架构和运营相关的多个任务及问题，从而使开发团队可以仅专注于编码和创新。
Kubernetes最初源于谷歌内部的Borg，提供了面向应用的容器集群部署和管理系统。Kubernetes的目标旨在消除编排物理/虚拟计算，网络和存储基础设施的负担，并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。Kubernetes 也提供稳定、兼容的基础（平台），用于构建定制化的workflows 和更高级的自动化任务。 Kubernetes 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。 Kubernetes 还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。参考技术B kubernetes是一个轻便的和可扩展的开源平台，用于管理容器化应用和服务。通过kubernetes能够进行应用的自动化部署和扩缩容。在kubernetes中，会将组成应用的容器组合成一个逻辑单元以更易管理和发现。kubernetes积累了作为Google生产环境运行工作负载15年的经验，并吸收了来自于社区的最佳想法和实践。
kubernetes功能：
1、自动装箱
基于容器对应用运行环境的资源配置要求自动部署应用容器。
2、自愈能力
当容器失败时，会对容器进行重启。
当所部署的Node节点有问题时，会对容器进行重新部署和重新调度。
当容器未通过监控检查时，会关闭此容器。
直到容器正常运行时，才会对外提供服务。
3、水平扩展
通过简单的命令、用于UI界面或基于CPU等资源使用情况，对应用容器进行规模扩大或规模剪裁。
4、服务发现
用户不需要使用额外的服务发现机制，就能够基于kubernetes自身能力实现服务发现和负载均衡。
5、滚动更新
可以根据应用的变化，对应用容器运行的应用，进行一次性或批量式更新。
6、存储编排
自动实现存储系统挂载及应用，特别对有状态应用实现数据持久化非常重要存储系统可以来自于本地目录、网络存储公共云存储服务等。

Kubernetes 中的“端点”是啥？

【中文标题】Kubernetes 中的“端点”是啥？【英文标题】：What is an 'endpoint' in Kubernetes?Kubernetes 中的“端点”是什么？ 【发布时间】：2019-03-22 07:21:55 【问题描述】：

我是 Kubernetes 新手，开始阅读文档。经常使用术语“端点”，但文档缺乏明确的定义。

就 Kubernetes 而言，什么是“端点”？它位于哪里？

我可以想象“端点”是单个“节点”的某种接入点，但这只是一个猜测。

【问题讨论】：

您是在谈论服务中使用的Endpoint 资源还是您指的是哪个资源？你能举个例子吗？我在这篇文章 kubernetes.io/docs/concepts/services-networking/service 中偶然发现了“端点”。为什么端点 ip 与 clusterip 不同？如果需要的是集群内的端点 ip，为什么 nslookup 会将服务解析为集群 ip？ 【参考方案1】：

将 Endpoints 视为“到达应用程序的最终目的地”或“最后的事情”

如下例所示：pod-IP = 10.32.0.2, service-Port* = 3306, endpoint = [pod-IP] :[服务端口]

因此，用户 Bob 要访问 MySql 应用程序，它应该寻址到 10.32.0.2:3306，这是网络中他可以找到所需信息的最后一个节点。

一个简单示例：在这种情况下，我想为我/浏览器访问 Google Mail，端点将是 gmail.com:443 与上面的示例类似 [pod-IP]:[服务端口]

【讨论】：

【参考方案2】：

端点是一种资源，它获取动态分配给它的一个或多个 Pod 的 IP 地址以及端口。可以使用kubectl get endpoints 查看端点。

一个端点资源被一个 kubernetes 服务引用，以便该服务记录 pod 的内部 IP，以便能够与它们通信。

我们需要端点作为抽象层，因为 Kubernetes 中的“服务”充当编排的一部分，以确保将流量分配到 pod（包括仅将流量发送到健康的 pod）。例如，如果一个 pod 死了，将生成一个替换 pod，并使用新的 IP 地址。从概念上讲，死 pod IP 将从端点对象中移除，并添加新创建的 pod 的 IP，以便更新服务并“知道”要连接到哪些 pod。

阅读“向集群公开 pod”，然后在此处阅读“创建服务” - https://kubernetes.io/docs/concepts/services-networking/connect-applications-service/#exposing-pods-to-the-cluster

调查和查看关系的简单方法是：

kubectl describe pods - 观察你的 Pod 的 IP 地址 kubectl get ep - 并观察分配给您的端点的 IP 地址 kubectl describe service myServiceName - 并观察与您的服务关联的 Endpoints

所以不，端点与单个节点的 IP 没有任何关系。我发现了解 Kubernetes 的整体结构以及集群、节点、服务、端点和 Pod 之间的关系很有用。此图很好地总结了它，并显示了导致 OSI 第 2 层（TCP 层）到达后端节点 1 的入口流，而 OSI 第 7 层（http 层）入口最终到达 Pod 1 中的“Web 容器 1” ：

【讨论】：

为什么用户向Node(10.10.50.51)而不是clusterIP(10.111.239.70)发送请求？集群 IP 无法在集群外访问。【参考方案3】：

虽然您是正确的，在 glossary 中确实没有端点条目，但它是一个定义明确的 Kubernetes 网络概念或抽象。由于它是次要的，你通常不会直接操纵它。定义了一个核心资源Endpoint，命令行也支持它：

$ kubectl get endpoints
NAME         ENDPOINTS            AGE
kubernetes   192.168.64.13:8443   10d

您会看到它实际上是什么：IP 地址和端口。通常，您会让服务管理端点（服务将流量路由到的每个 pod 一个 EP），但如果您有需要的用例，您也可以manually manage 它们。

【讨论】：

在进一步阅读 Kubernetes 中的“端点”之后，我现在将其理解为填充在 Kubernates API server 上的 REST API endpoint 的面向对象表示。因此，就 Kubernetes 而言，“端点”是访问其资源（例如 Pod）的方式——“端点”背后的资源。感谢您的回答。有趣的是，术语表中没有定义端点。我知道这不是 Kubernetes 特有的术语……但服务也不是。或服务帐户。或音量。或节点。或容器！ ?【参考方案4】：

在我的例子中，我在注释中遇到了语法问题

metadata:
  name: academy
  namespace: qa
  resourceVersion: '12761882'
  generation: 1
  creationTimestamp: '2021-06-22T03:21:43Z'
  labels:
    app.kubernetes.io/instance: academy-platform-qa
    app.kubernetes.io/managed-by: Tiller
    app.kubernetes.io/name: academy
    helm.sh/chart: academy-qa-v0.6.8-0-gef467c2
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/whitelist-source-range: >-
      10.16.0.27/8, 69.114.20.139/32,

如你所见，我在 69.114.20.139/32 之后离开了 ',' 我固定到

metadata:
  name: academy
  namespace: qa
  resourceVersion: '12761882'
  generation: 1
  creationTimestamp: '2021-06-22T03:21:43Z'
  labels:
    app.kubernetes.io/instance: academy-platform-qa
    app.kubernetes.io/managed-by: Tiller
    app.kubernetes.io/name: academy
    helm.sh/chart: academy-qa-v0.6.8-0-gef467c2
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/whitelist-source-range: >-
      10.16.0.27/8, 69.114.20.139/32

【讨论】：

【参考方案5】：

我会一一回答你的问题：

就 Kubernetes 而言，什么是“端点”？

（K8S中资源名称为Endpoints）。

Endpoints 是 kubernetes 中的一个对象，它代表一个……端点列表。这些端点可以是：

一个在集群内运行的内部 pod - 这是比较熟悉的形式。当我们创建服务和 Pod 并将服务标签选择器与 Pod 标签匹配时，它会在后台自动为我们创建。

不是 pod 的外部 IP - 这是最不为人知的选项。

外部 IP 可以驻留在集群之外 - 例如外部 Web 服务器或数据库。它也可以驻留在不同的命名空间中 - 如果您想将您的服务指向集群内不同命名空间中的服务。

关于外部端点 - 如果您没有在服务中指定标签选择器 - Kubernetes 无法创建端点列表，因为他不知道服务应该包含和代理哪些 pod。

它在哪里？

就像这里提供的很棒的图表一样 - 它位于服务和内部（pod）或外部（网络服务器、数据库等）之间资源。

我可以想象“端点”是某种接入点单个“节点”它是对位于内部的资源的访问点集群中的一个节点。

端点可以驻留在集群中的一个节点内，也可以驻留在集群/环境之外。

如果它是一个 internal 端点（这意味着 pod 标签与服务标签选择器匹配） - 您可以通过以下方式访问它：

$kubectl describe svc/my-service


Name:                     my-service
Namespace:                default
Labels:                   <none>
Annotations:              kubectl.kubernetes.io/last-applied-configuration:
                            "apiVersion":"v1","kind":"Service","metadata":"annotations":,"name":" my-service","namespace":"...
Selector:                 run=some-run
Type:                     NodePort
IP:                       10.100.92.162
Port:                     <unset>  8080/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  31300/TCP
Endpoints:                172.21.21.2:80,172.21.38.56:80,172.21.39.160:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

或直接使用：

$kubectl get endpoints my-service

NAME           ENDPOINTS                                       AGE
my-service   172.21.21.2:80,172.21.38.56:80,172.21.39.160:80   63d

关于外部端点：

您创建一个没有标签选择器的服务：

apiVersion: v1
kind: Service
metadata:
  name: my-service #<------ Should match the name of Endpoints object
spec:
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 9376

因此不会自动创建相应的 Endpoint 对象，您需要手动添加 Endpoints 对象并将 Service 映射到运行外部资源的所需网络地址和端口：

apiVersion: v1
kind: Endpoints
metadata:
  name: my-service #<------ Should match the name of Service
subsets:
  - addresses:
      - ip: 192.0.2.45
    ports:
      - port: 9376

（注意：）我使用术语 internal 来表示与标签选择器和术语 external 用于手动创建的端点。

我可以使用 auto-generated 和 manual 这两个术语来代替 - 这会更准确，但我认为也更令人困惑。

在大多数情况下，当 Endpoints 与我们集群中的 pod 相关时——我们希望它们也由 K8S 管理——在这种情况下，它们也需要由 K8S 生成。

【讨论】：

【参考方案6】：

在 k8s 中，Endpoints 由分布式 API 组成，例如“[IP]:[Port]”等。但是，在 SOAP 中，Endpoint 是一个类似于 URL 的分布式 API。

from Google Cloud: