Kubernetes（简称K8s，是因为 k 和 s 之间有八个字符）是一个开源的容器编排平台，用于管理云平台中多个主机上的容器化应用程序。它提供了一种机制，用于自动化部署、扩展和管理容器化应用程序的集群。Kubernetes的目标是让部署容器化应用程序变得简单高效。它提供了应用程序部署、规划、更新和维护的基本机制，同时具备强大的扩展性和可靠性。Kubernetes采用主从设备模型（Master-Slave架构），其中Master节点负责核心的调度、管理和运维任务，而Slave节点负责运行应用程序的容器。通过Kubernetes，开发人员可以更轻松地管理和扩展他们的容器化应用程序，从而提高应用程序的可靠性和可伸缩性。

特性

主要特性：

自动化容器编排：弹性伸缩，Kubernetes可以自动化地管理和编排容器，根据定义的规则和策略来调度和部署应用程序。
服务发现和负载均衡：Kubernetes提供了内置的服务发现机制，可以自动为应用程序创建稳定的网络地址，并通过负载均衡将流量分发到不同的容器实例。
自动扩展和弹性伸缩：Kubernetes可以根据负载情况自动调整容器的数量，实现应用程序的弹性伸缩，确保始终具有所需的资源。
自我修复和健康检查：Kubernetes具有自我修复机制，可以监测容器的健康状态，并在出现故障或异常时自动进行恢复或重启。
配置和存储管理：Kubernetes提供了集中化的配置管理工具，可以轻松管理应用程序的配置信息。支持外部存储系统的挂载，并对外部存储资源进行编排。无论是本地存储、公有云提供的存储服务（如AWS）还是网络存储（如NFS、Glusterfs、Ceph），都可以作为集群资源使用，提高存储的灵活性。
集中化配置管理和密钥管理：Kubernetes提供了集中化的配置管理工具，可以管理敏感数据和应用程序配置，提高数据安全性。同时，它还支持密钥管理，用于安全地存储和使用敏感信息。
滚动更新和回滚：Kubernetes支持滚动更新，可以逐步替换旧版本的容器，确保应用程序的平滑升级。如果出现问题，还可以回滚到之前的版本。
多租户支持：Kubernetes支持多租户的部署模式，可以将不同的应用程序或团队隔离开来，确保安全性和资源隔离。
可扩展性和插件机制：Kubernetes具有高度可扩展的架构，并提供了插件机制，可以根据需要添加自定义功能或集成其他工具。
跨平台和多云支持：Kubernetes可以在各种云平台和基础设施上运行，包括公有云、私有云和混合云环境。
声明式配置和版本控制：Kubernetes采用声明式配置的方式，通过定义期望的状态来管理应用程序，同时支持版本控制和回滚。
任务批处理运行：Kubernetes支持一次性任务和定时任务，适用于批量数据处理和分析的场景，满足批处理需求。

作用（为什么使用）

传统的后端部署方式：把程序包（包括可执行二进制文件、配置文件等）放到服务器上，接着运行启动脚本把程序跑起来，同时启动守护脚本定期检查程序运行状态、必要的话重新拉起程序。

设想，如果服务的请求量较多，已部署的服务响应不过来怎么办？如果请求量、内存、CPU超过阈值做了告警，运维人员马上再加几台服务器，部署好服务之后，接入负载均衡来分担已有服务的压力。
但是，从监控告警到部署服务，中间需要人力介入！那么，有没有办法自动完成服务的部署、更新、卸载和扩容、缩容呢？

k8s就是为了解决这些问题设计的：

它提供了自动化的容器编排和管理功能，使得部署、更新、扩容和缩容等操作更加简单和高效。
通过使用Kubernetes，可以将容器化的应用程序打包成镜像，并通过Kubernetes进行部署。Kubernetes会自动管理容器的运行状态，监控容器的健康状况，并在需要时进行自动恢复。当请求量增加时，Kubernetes可以根据负载情况自动扩展容器的数量，以满足高负载需求。而当请求量减少时，Kubernetes也可以自动缩减容器的数量，以节省资源和成本。
此外，Kubernetes还提供了服务发现和负载均衡的功能，使得容器化的应用程序可以方便地进行服务间通信，并实现负载均衡，提高应用程序的可用性和性能。
总之，Kubernetes的目标是简化容器化应用程序的部署和管理，提供自动化的运维能力，减少人工介入，提高效率和可靠性。它是现代化应用程序架构的重要组成部分，可以帮助更好地应对不断增长的业务需求和流量压力。

Kubernetes（K8S）的目标是简化和高效地部署容器化应用程序。它解决了使用裸跑Docker时的一些问题，包括：

单机使用无法有效地进行集群管理。
随着容器数量增加，管理成本也随之上升。
缺乏有效的容灾和自愈机制。
没有预设的编排模板，无法实现快速、大规模的容器调度。
缺乏统一的配置管理中心工具。
缺乏容器生命周期的管理工具。
缺乏图形化的运维管理工具。

Kubernetes是由Google开源的容器集群管理系统，它在Docker等容器技术的基础上提供了一系列完整的功能，包括应用程序的部署运行、资源调度、服务发现和动态伸缩等。它提高了大规模容器集群管理的便捷性。其主要功能包括：

使用Docker等容器技术对应用程序进行打包、实例化和运行。
以集群的方式运行和管理分布在多台机器上的容器。
解决了跨机器容器之间通信的问题。
Kubernetes的自我修复机制确保容器集群始终处于用户期望的状态。

k8s架构

Kubernetes（简称K8s）是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用程序。Kubernetes的架构由多个组件组成，每个组件负责不同的任务，协同工作以实现高可用性和弹性。

以下是Kubernetes的主要组件和其功能：

API Server（API服务器）：作为Kubernetes的网关，接收和处理所有的指令请求。它提供了一组RESTful API，用于管理和操作Kubernetes集群中的资源对象。
Scheduler（调度器）：负责根据预定义的调度算法，将容器化应用程序的资源请求调度到合适的节点上运行。调度器考虑节点的资源利用率、健康状态和亲和性等因素来做出决策。
Controller Manager（控制器管理器）：维护Kubernetes中的各种控制器，用于管理和控制资源对象的生命周期。控制器可以监视资源对象的状态变化，并根据预定义的规则执行相应的操作，如创建、删除、更新和修改资源对象。
etcd：是Kubernetes的分布式键值存储系统，用于存储集群的配置数据和状态信息。etcd提供高可用性和一致性，可以用于服务注册、发现和配置同步等功能。
Kubelet：运行在每个节点上的代理程序，负责管理节点上的容器和容器化应用程序。Kubelet与API Server通信，接收指令并执行相应的操作，如创建、销毁和监控容器。
Container Runtime（容器运行时）：负责在节点上运行容器，如Docker、containerd等。容器运行时提供了容器的生命周期管理、资源隔离和安全性等功能。
kube-proxy：负责在集群中实现服务发现和负载均衡。它维护网络规则，将服务请求转发到正确的目标容器。

这些组件共同协作，实现了Kubernetes的核心功能，包括容器编排、自动伸缩、服务发现、负载均衡和故障恢复等。通过这种架构，Kubernetes能够提供高度可靠和可扩展的容器化应用程序管理平台

k8s工作流程

运维人员向API Server发出创建Pod的请求，告诉它我想干什么，我的期望是什么。
API Server响应请求，并通过一系列认证和授权过程，将请求存储到etcd（分布式键值存储系统），并通知Controller Manager。
Controller Manager通过API Server读取etcd中的请求，并按照预设的模板去创建Pod。创建完成后，将Pod的数据写入etcd。
Controller Manager通过API Server去找Scheduler，为新创建的Pod选择最适合的Node节点。Scheduler会根据预算策略在所有Node节点中挑选最优的节点。
Scheduler选择合适的Node节点后，将选择结果返回给Controller Manager。
Controller Manager将选择结果通过API Server写入etcd，更新Pod的状态。
Kubelet（运行在每个节点上的代理程序）通过API Server获取到更新后的Pod状态，并根据状态执行相应的操作，如创建、销毁和监控容器。
Container Runtime（容器运行时）在选定的Node节点上运行容器，如Docker、containerd等。容器运行时负责容器的生命周期管理、资源隔离和安全性等功能。
kube-proxy负责在集群中实现服务发现和负载均衡。它维护网络规则，将服务请求转发到正确的目标容器。

通过这个工作流程，Kubernetes实现了自动化的容器编排和管理，确保应用程序的高可用性、弹性和可扩展性。各个组件之间的协作和通信，使得Kubernetes能够有效地管理容器化应用程序，并提供强大的功能和服务。

k8s集群架构与组件

Kubernetes（K8S）是一个分布式系统，它的集群架构由多个组件组成，每个组件负责不同的任务。Kubernetes（K8S）的架构采用了主从设备模型（Master-Slave 架构）。在 K8S 中，Master 节点负责集群的调度、管理和运维，而 Worker Node 节点则承载着实际的工作负载。

Master节点（控制平面）：
kube-apiserver：提供Kubernetes API的前端接口，用于与其他组件通信。
etcd：可靠的分布式键值存储，用于存储集群的配置数据和状态信息。
kube-scheduler：负责根据资源需求和约束条件，将Pod调度到合适的工作节点上运行。
kube-controller-manager：包含多个控制器，负责监控和管理集群的各种资源和控制器。
cloud-controller-manager（可选）：用于与云平台提供商集成，管理云资源。
工作节点（计算节点）：
kubelet：与Master节点通信，负责管理并执行Pod的生命周期，包括创建、启动、监控和销毁Pod。
kube-proxy：负责为Pod提供网络代理和负载均衡功能，实现Kubernetes服务的访问和通信。
网络插件：
Kubernetes使用网络插件来实现容器之间和容器与外部网络的通信。不同的网络插件可以提供不同的网络解决方案，如Overlay网络、主机网络等。
存储插件：
Kubernetes支持不同的存储插件，用于提供持久化存储的功能，如本地存储、网络存储、云存储等。
DNS插件：
Kubernetes集群通常会配置一个DNS插件，用于为Pod提供域名解析服务，使得Pod可以通过域名进行相互通信。
Dashboard（可选）：
Kubernetes提供了一个Web界面，称为Dashboard，用于可视化地管理和监控集群中的应用程序和资源。

核心组件详解

Master节点

Kube-apiserver

kube-apiserver是Kubernetes集群中的一个核心组件，它是Kubernetes API的前端接口，负责处理来自用户和其他组件的请求，并将其转发到相应的组件进行处理。

API接口：kube-apiserver提供了一组RESTful API接口，用于管理和操作Kubernetes集群中的各种资源，如Pod、Service、Deployment等。通过这些API接口，用户和其他组件可以与集群进行交互。
认证和授权：kube-apiserver支持多种认证和授权机制，如基于Token的认证、基于证书的认证、OpenID Connect等。它可以验证用户的身份，并根据配置的访问控制策略对请求进行授权。
数据存储：kube-apiserver使用etcd作为后端存储，将集群的配置数据和状态信息持久化保存在etcd中。etcd是一个可靠的分布式键值存储系统，确保集群的元数据在节点故障或重启后仍然可用。
高可用性：为了提高kube-apiserver的可用性，可以运行多个kube-apiserver实例，并使用负载均衡器将请求分发到这些实例上。这样即使其中一个实例发生故障，其他实例仍然可以继续提供服务。
安全性：kube-apiserver提供了一些安全机制来保护API的访问和数据的安全性。它支持TLS加密通信，可以配置访问控制策略来限制用户的权限，还可以启用审计日志记录API的访问和操作。
扩展性：kube-apiserver具有良好的扩展性，可以通过自定义资源定义（Custom Resource Definition）和自定义控制器（Custom Controller）来扩展API，以满足特定的业务需求。

kube-apiserver是Kubernetes集群中非常重要的组件，用于暴露 Kubernetes API，任何资源请求或调用操作都是通过 kube-apiserver 提供的接口进行。以 HTTP Restful API 提供接口服务，所有对象资源的增删改查和监听操作都交给 API Server 处理后再提交给 Etcd 存储。可以理解成 API Server 是 K8S 的请求入口服务。API Server 负责接收 K8S 所有请求（来自 UI 界面或者 CLI 命令行工具），然后根据用户的具体请求，去通知其他组件干活。可以说 API Server 是 K8S 集群架构的大脑。

Kube-controller-manager

kube-controller-manager是Kubernetes集群中的一个核心组件，它是控制器的集合，负责管理和运行多个控制器，以确保集群中的各种资源处于期望的状态。

控制器集合：kube-controller-manager包含了多个控制器，每个控制器负责监控和管理集群中的不同资源。常见的控制器包括副本控制器（Replication Controller）、节点控制器（Node Controller）、服务控制器（Service Controller）等。
副本控制器：副本控制器负责确保Pod的副本数量与期望的副本数量保持一致。它会监控Pod的状态，并在需要时创建、删除或重新调度Pod，以满足用户定义的副本数量。
节点控制器：节点控制器负责监控集群中的节点状态，并根据需要进行节点的添加、删除或重新调度。它会检测节点的健康状态，并根据节点的可用性和资源情况来进行节点管理。
服务控制器：服务控制器负责监控Service资源的变化，并确保集群中的服务始终具有稳定的网络地址。它会自动为Service创建对应的负载均衡器，并将流量分发到后端的Pod实例。
控制循环：每个控制器都遵循控制循环（Control Loop）的模式，不断地监控资源的状态，并根据期望的状态进行调整。控制循环包括观察资源状态、比较当前状态和期望状态、执行操作来调整资源状态等步骤。
高可用性：为了提高kube-controller-manager的可用性，可以运行多个实例，并使用负载均衡器将请求分发到这些实例上。这样即使其中一个实例发生故障，其他实例仍然可以继续提供服务。
自定义控制器：除了内置的控制器，kube-controller-manager还支持自定义控制器的扩展。用户可以根据自己的需求编写自定义控制器，以实现特定的业务逻辑和资源管理。

运行管理控制器，是 K8S 集群中处理常规任务的后台线程，是 K8S 集群里所有资源对象的自动化控制中心。在 K8S 集群中，一个资源对应一个控制器，而 Controller manager 就是负责管理这些控制器的。由一系列控制器组成，通过 API Server 监控整个集群的状态，并确保集群处于预期的工作状态，比如当某个 Node 意外宕机时，Controller Manager 会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。

Kube-scheduler

kube-scheduler是Kubernetes集群中的一个核心组件，它负责根据预定义的调度策略，为新创建的Pod选择合适的节点进行调度。

节点选择：kube-scheduler会根据一系列的调度策略和规则，选择最适合的节点来运行Pod。这些策略包括资源需求、亲和性（Affinity）和反亲和性（Anti-Affinity）、节点亲和性（Node Affinity）、节点亲和性预选（Node Affinity Preemption）等。
资源需求：kube-scheduler会考虑Pod的资源需求（如CPU、内存等），并选择具有足够资源的节点来运行Pod，以避免资源竞争和过载。
亲和性和反亲和性：kube-scheduler支持亲和性和反亲和性规则，可以将Pod调度到与其他Pod或节点具有特定关系的节点上。例如，可以将具有相同标签的Pod调度到同一个节点上，或者将Pod调度到与特定Pod或节点具有反亲和性的节点上。
节点亲和性：kube-scheduler支持节点亲和性规则，可以将Pod调度到与特定节点具有特定关系的节点上。例如，可以将Pod调度到与具有特定标签的节点具有亲和性的节点上。
节点亲和性预选：kube-scheduler支持节点亲和性预选规则，可以在调度过程中优先考虑具有特定标签或特定条件的节点。这可以用于实现高级调度策略，如将Pod调度到具有特定硬件或软件配置的节点上。
可扩展性：kube-scheduler具有良好的可扩展性，可以通过自定义调度器（Custom Scheduler）来扩展其功能。用户可以根据自己的需求编写自定义调度器，以实现特定的调度策略和资源管理。
高可用性：为了提高kube-scheduler的可用性，可以运行多个实例，并使用负载均衡器将请求分发到这些实例上。这样即使其中一个实例发生故障，其他实例仍然可以继续提供调度服务。

可以理解成 K8S 所有 Node 节点的调度器。当用户要部署服务时，Scheduler 会根据调度算法选择最合适的 Node 节点来部署 Pod。 •预选策略（predicate） •优选策略（priorities）

API Server 接收到请求创建一批 Pod ，API Server 会让 Controller-manager 按照所预设的模板去创建 Pod，Controller-manager 会通过 API Server 去找 Scheduler 为新创建的 Pod 选择最适合的 Node 节点。比如运行这个 Pod 需要 2C4G 的资源，Scheduler 会通过预选策略过滤掉不满足策略的 Node 节点。Node 节点中还剩多少资源是通过汇报给 API Server 存储在 etcd 里，API Server 会调用一个方法找到 etcd 里所有 Node 节点的剩余资源，再对比 Pod 所需要的资源，如果某个 Node 节点的资源不足或者不满足预选策略的条件则无法通过预选。预选阶段筛选出的节点，在优选阶段会根据优先策略为通过预选的 Node 节点进行打分排名，选择得分最高的 Node。例如，资源越富裕、负载越小的 Node 可能具有越高的排名。

存储中心

etcd

etcd是一个开源的分布式键值存储系统，它被广泛应用于Kubernetes集群中作为存储和同步集群配置数据的后端。

分布式键值存储：etcd提供了一个简单而强大的分布式键值存储系统，类似于一个分布式的字典或数据库。它允许用户存储和检索键值对，并支持对数据的高效查询和事务操作。
一致性和可靠性：etcd使用Raft一致性算法来确保数据的一致性和可靠性。Raft算法通过选举和复制日志的方式，保证了集群中的节点之间的数据一致性，并在节点故障或网络分区的情况下保持系统的可用性。
高可用性：etcd支持多节点部署，可以运行多个etcd实例组成一个集群。这样即使其中一个节点发生故障，其他节点仍然可以继续提供服务，保证了系统的高可用性。
集群配置存储：在Kubernetes中，etcd被用作存储和同步集群的配置数据，包括节点信息、Pod和Service的状态、配置文件等。etcd存储了整个集群的元数据，确保集群中的各个组件和资源的状态保持一致。
监控和调试：etcd提供了一些工具和接口，用于监控和调试集群的状态和性能。用户可以通过etcd的API接口或命令行工具来查询和监控存储的数据，并进行故障排除和性能优化。
安全性：etcd支持TLS加密通信，可以配置访问控制策略来限制对存储数据的访问权限。它还提供了身份验证和授权机制，确保只有经过授权的用户才能访问和修改存储的数据。

K8S 的存储服务。etcd 是分布式键值存储系统，存储了 K8S 的关键配置和用户配置，K8S 中仅 API Server 才具备读写权限，其他组件必须通过 API Server 的接口才能读写数据。

Node

Kubelet

kubelet是Kubernetes集群中每个节点上的主要组件之一，它负责管理和监控节点上的容器。

容器生命周期管理：kubelet负责管理节点上的容器的生命周期，包括创建、启动、停止和销毁容器。它会监控容器的状态，并根据需要执行相应的操作，以确保容器按预期运行。
Pod和容器配置：kubelet根据来自Kubernetes API Server的指令，负责创建和管理Pod。它会根据Pod的配置信息，如容器镜像、资源需求、环境变量等，来创建和配置容器。
资源管理：kubelet会监控节点上的资源使用情况，包括CPU、内存、存储等，并根据Pod的资源需求进行资源分配和管理。它会确保节点上的容器不会超出资源限制，以避免资源竞争和过载。
健康检查和自愈机制：kubelet会定期对容器进行健康检查，检测容器的运行状态和健康状况。如果容器出现故障或异常，kubelet会尝试重新启动容器，以恢复容器的正常运行。
日志和监控：kubelet会收集容器的日志和监控数据，并将其发送到集中化的日志和监控系统，以便用户和管理员进行查看和分析。这有助于故障排除和性能优化。
安全性：kubelet负责确保节点上的容器的安全性。它会执行容器的安全策略，如限制容器的权限、隔离容器的网络等，以保护节点和集群的安全。
与其他组件的通信：kubelet与其他Kubernetes组件，如kube-apiserver、kube-proxy等进行通信，以获取指令、报告状态和接收更新。它通过与这些组件的交互，实现了集群的协调和管理。

在 Kubernetes 集群中，在每个 Node（又称 Worker Node）上都会启动一个 kubelet 服务进程。该进程用于处理 Master 下发到本节点的任务，管理 Pod 及 Pod 中的容器。每个 kubelet 进程都会在 API Server 上注册节点自身的信息，定期向 Master 汇报节点资源的使用情况，并通过 cAdvisor 监控容器和节点资源。

Kube-Proxy

服务代理：kube-proxy通过监听Kubernetes API Server上的Service和Endpoint对象的变化，动态地维护一个服务代理表。它会为每个Service创建一个虚拟IP，并将流量转发到后端的Pod实例。
负载均衡：kube-proxy使用负载均衡算法将流量分发到后端的Pod实例。它支持多种负载均衡模式，如轮询、随机、最少连接等，以确保流量在Pod之间均匀分布。

在每个 Node 节点上实现 Pod 网络代理，是 Kubernetes Service 资源的载体，负责维护网络规则和四层负载均衡工作。负责写入规则至iptables、ipvs实现服务映射访问的。 Kube-Proxy 本身不是直接给 Pod 提供网络，Pod 的网络是由 Kubelet 提供的，Kube-Proxy 实际上维护的是虚拟的 Pod 集群网络。 Kube-apiserver 通过监控 Kube-Proxy 进行对 Kubernetes Service 的更新和端点的维护。在 K8S 集群中微服务的负载均衡是由 Kube-proxy 实现的。Kube-proxy 是 K8S 集群内部的负载均衡器。它是一个分布式代理服务器，在 K8S 的每个节点上都会运行一个 Kube-proxy 组件。

网络通信模型

在Kubernetes（K8S）中，网络模型是用于管理和组织容器之间通信的一种架构。Kubernetes使用了一种称为"容器网络接口"（Container Network Interface，CNI）的标准，来定义和实现容器之间的网络通信。

Pod内部容器之间的网络通信：在同一个Pod中的容器可以通过localhost进行直接通信，它们共享相同的网络命名空间和IP地址。
Pod之间的网络通信：不同Pod中的容器之间的通信需要通过网络进行。每个Pod都被分配一个唯一的IP地址，可以通过该IP地址进行通信。Pod之间的通信是通过网络插件（如Flannel、Calico、Weave等）来实现的。
Pod到Service之间的网络通信：Kubernetes中的Service是一种抽象，用于将一组Pod封装为一个逻辑服务。Service会为这些Pod分配一个虚拟IP地址，并通过负载均衡将流量分发到这些Pod上。其他Pod可以通过Service的虚拟IP地址来访问该服务。
集群外部与内部组件之间的网络通信：Kubernetes集群外的组件（如外部服务、其他集群、云服务等）可以通过Kubernetes提供的网络代理或Ingress来与集群内的服务进行通信。网络代理和Ingress可以将外部流量转发到集群内部的Service或Pod。

具体的网络实现取决于所选择的网络插件和配置。常见的网络插件包括Flannel、Calico、Weave等，它们提供了不同的网络方案和功能，以满足不同的需求和环境。这些网络插件通过创建虚拟网络、路由规则和网络策略等方式，实现了Kubernetes中的网络模型。

在Kubernetes中，有三个与IP地址相关的概念：Node IP、Pod IP和Cluster IP。

Node IP（节点IP）：Node IP是指Kubernetes集群中每个节点（Node）所分配的IP地址。每个节点都有一个唯一的Node IP，用于标识和访问该节点。Node IP通常用于集群外部与节点进行通信，例如从外部网络访问节点上运行的服务。
Pod IP（容器组IP）：Pod IP是指Kubernetes集群中每个Pod所分配的IP地址。Pod是Kubernetes中最小的可调度和可管理的单元，每个Pod都有一个唯一的Pod IP。Pod IP用于容器之间的通信，不同Pod中的容器可以通过Pod IP进行网络通信。
Cluster IP（集群IP）：Cluster IP是指Kubernetes集群中Service所分配的虚拟IP地址。Service是Kubernetes中用于封装一组Pod的逻辑服务，为这些Pod提供一个统一的入口。Cluster IP是Service的虚拟IP地址，用于在集群内部进行服务发现和访问。其他Pod可以通过Cluster IP来访问Service提供的服务。

这些IP地址在Kubernetes中起着不同的作用，Node IP用于集群外部与节点通信，Pod IP用于容器之间的通信，而Cluster IP用于集群内部的服务发现和访问。它们共同构成了Kubernetes中的网络基础设施。

容器引擎

在Kubernetes（K8S）中，并没有单独的容器引擎。Kubernetes本身并不提供容器运行时，而是通过与容器运行时接口（Container Runtime Interface，CRI）兼容的容器运行时来运行和管理容器。

CRI是Kubernetes定义的一种接口规范，用于与容器运行时进行通信和交互。它允许Kubernetes与不同的容器运行时进行集成，例如Docker、Containerd、CRI-O等。这些容器运行时负责实际的容器创建、管理和执行工作。

常见的Kubernetes容器运行时包括：

Docker：Docker是最常用的容器运行时之一，它提供了广泛的功能和工具，用于创建、打包和运行容器。在较早的Kubernetes版本中，Docker是默认的容器运行时。
Containerd：Containerd是一个轻量级的容器运行时，它是Docker的核心组件之一。Containerd提供了基本的容器管理功能，可以与Kubernetes集成，作为Kubernetes的容器运行时。
CRI-O：CRI-O是一个专门为Kubernetes设计的轻量级容器运行时，它符合CRI规范，并专注于提供最小化的容器运行时功能。CRI-O使用runc作为底层容器执行器，与Kubernetes紧密集成。

除了上述容器运行时，还有其他一些实现了CRI规范的容器运行时，如rkt（现已停止开发）、frakti等。这些容器运行时都可以与Kubernetes集成，作为Kubernetes的容器运行时。

k8s核心概念详解

Kubernetes 包含多种类型的资源对象：Pod、Label、Service、Replication Controller 等。

Pod（容器组）：Pod是Kubernetes中最小的可调度和可管理的单元，它可以包含一个或多个容器，并共享相同的网络和存储资源。Pod是部署和扩展应用程序的基本单位。
Label（标签）：Label是用于标识和组织Kubernetes资源的键值对。通过为资源对象添加标签，可以对它们进行分类、选择和操作。标签可以用于实现资源的分组、服务发现、负载均衡等功能。
Service（服务）：Service是一种抽象，用于封装一组Pod，并为它们提供一个统一的入口。Service为这些Pod分配一个虚拟IP地址，并通过负载均衡将流量分发到这些Pod上，实现了服务的访问和通信。
Namespace（命名空间）：Namespace是用于在Kubernetes集群中创建多个虚拟集群的一种机制。通过使用命名空间，可以将不同的资源对象隔离开来，实现资源的多租户和资源隔离。
Controller（控制器）：Controller是一种用于管理和控制资源对象的机制。Kubernetes提供了多种类型的控制器，如副本控制器、服务控制器等，用于监控和管理集群中的各种资源。
Replication Controller（副本控制器）：Replication Controller用于确保Pod的副本数量与期望的副本数量保持一致。它会监控Pod的状态，并在需要时创建、删除或重新调度Pod，以满足用户定义的副本数量。

Kubernetes通过这些核心概念和机制，实现了容器化应用程序的部署、管理和扩展。它提供了丰富的功能和工具，使得应用程序的部署和运维变得更加简单和高效。

所有的资源对象都可以通过 Kubernetes 提供的 kubectl 工具进行增、删、改、查等操作，并将其保存在 etcd 中持久化存储。 Kubernets其实是一个高度自动化的资源控制系统，通过跟踪对比etcd存储里保存的资源期望状态与当前环境中的实际资源状态的差异，来实现自动控制和自动纠错等高级功能。

Pod

它是最小的可部署单元。一个Pod可以包含一个或多个容器，这些容器共享相同的网络和存储资源，并在同一主机上运行。

Pod提供了一个抽象层，用于封装应用程序的运行环境。它可以包含应用程序所需的所有组件，如主应用程序容器、辅助容器（如日志收集器、辅助工具等）以及共享的存储卷。

Pod具有以下特点：

网络共享：Pod中的所有容器共享相同的网络命名空间和IP地址，它们可以通过localhost相互通信。
存储共享：Pod中的所有容器可以访问共享的存储卷，这使得它们可以共享数据和文件。
生命周期：Pod具有自己的生命周期，它可以被创建、启动、停止和销毁。当Pod被销毁时，其中的所有容器也会被终止。
调度和部署：Pod可以由Kubernetes调度器在集群中的节点上进行部署。调度器会考虑节点的资源和约束条件，选择适合的节点来运行Pod。

Pod是临时性的，它可以根据需要创建和销毁。如果需要长期运行的实例，可以使用Pod控制器（如Deployment、ReplicaSet等）来管理Pod的生命周期和副本数量。

Pod 控制器

Pod控制器是Kubernetes中的一种资源对象，用于管理和控制Pod的创建、更新和删除。Pod控制器包括以下几种类型：

ReplicaSet（副本集）：ReplicaSet确保指定数量的Pod副本在集群中运行。它可以根据需要进行自动扩展或缩减Pod的数量，以满足应用程序的需求。
Deployment（部署）：Deployment建立在ReplicaSet之上，它用于定义应用程序的期望状态，并确保该状态得到维持。Deployment支持滚动更新和回滚操作，可以方便地进行应用程序的发布和更新。
StatefulSet（有状态副本集）：StatefulSet用于管理有状态应用程序的Pod副本。它为每个Pod分配一个唯一的标识符，并提供稳定的网络标识和存储卷，确保有状态应用程序的数据持久性和顺序性。
DaemonSet（守护进程集）：DaemonSet用于在集群中的每个节点上运行一个Pod副本。它通常用于运行一些系统级别的服务，如日志收集、监控等。
Job（作业）：Job用于运行一次性任务或批处理任务。它确保任务成功完成，并可以设置重试策略和并行度。

这些Pod控制器提供了不同的功能和用途，可以根据应用程序的需求选择合适的控制器来管理Pod的生命周期。它们通过监控和调整Pod的数量和状态，确保应用程序的高可用性和可靠性。

Label

在Kubernetes中，Label（标签）是一种用于标识和组织资源的关键概念。它是一个键值对的元数据，可以附加到Kubernetes对象（如Pod、Service、Deployment等）上。

以下是一些关于标签的重要信息：

标签的结构：标签由键值对组成，例如"app=frontend"或"tier=backend"。键和值都是字符串类型，且键必须是唯一的。
标签的作用：标签可以用于对资源进行分类、筛选和选择。通过为资源添加标签，可以更方便地管理和操作它们。
标签的用途：标签可以用于多种用途，例如：
选择器（Selector）：可以使用标签选择器来选择具有特定标签的资源。这在创建Service、Deployment等对象时非常有用。
资源组织：可以使用标签将相关的资源进行分组和组织。例如，可以为所有属于同一应用程序的资源添加相同的标签。
资源管理：可以使用标签来跟踪和管理资源。通过为资源添加标签，可以更容易地识别和操作它们。
标签的添加和修改：可以在创建资源时为其添加标签，也可以在后续的操作中对标签进行修改。例如，可以使用kubectl命令行工具为Pod添加或修改标签。
标签的查询和选择：可以使用标签选择器来查询和选择具有特定标签的资源。选择器可以使用等于、不等于、存在、不存在等操作符进行条件筛选。

通过使用标签，可以更灵活地管理和操作Kubernetes中的资源。它提供了一种简单而强大的方式来组织、选择和管理资源，使得应用程序的部署和管理更加灵活和可靠。

Label 选择器

在Kubernetes中，标签选择器（Label selector）是一种用于查询和筛选具有特定标签的资源对象的机制。

标签选择器有两种类型：基于等值关系和基于集合关系。

基于等值关系的标签选择器：
=：选择具有指定标签键和值相等的资源对象。
!=：选择具有指定标签键但值不等于指定值的资源对象。
基于集合关系的标签选择器：
in：选择具有指定标签键且值在指定值列表中的资源对象。
notin：选择具有指定标签键但值不在指定值列表中的资源对象。
exists：选择具有指定标签键的资源对象。
!exists：选择没有指定标签键的资源对象。

以下是一个示例，展示如何使用标签选择器查询和筛选具有特定标签的Pod：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: nginx
  labels:
    app: my-app
    environment: production

要查询和筛选具有特定标签的Pod，可以使用标签选择器表达式，例如：

app=my-app：选择具有标签app的值为my-app的Pod。
environment!=development：选择具有标签environment的值不为development的Pod。
app in (my-app, your-app)：选择具有标签app的值为my-app或your-app的Pod。

Service 服务

Service（服务）是一种抽象的概念，用于定义一组Pod的访问方式和网络连接。Service为Pod提供了一个稳定的网络地址和DNS名称，使得其他应用程序可以通过该地址和名称与Pod进行通信。

Service的主要作用是实现负载均衡和服务发现。它将流量分发到后端的Pod，可以确保请求被均匀地分发到可用的Pod上，从而提高应用程序的可用性和性能。

在Kubernetes（K8S）集群中，每个Pod都有一个单独的IP地址。然而，由于Pod具有生命周期，可能会因为业务变更而销毁并重新创建，导致其IP地址也会改变。
为了解决这个问题，K8S引入了Service作为核心概念。在K8S中，Service并不是传统意义上的"服务"，而更像是一个网关层，用于提供一组Pod的对外访问接口和流量均衡。
Service通过标签选择器来确定作用于哪些Pod。在K8S集群中，客户端需要访问的服务就是Service对象。每个Service都有一个固定的虚拟IP（也称为Cluster IP），它会自动绑定到后端的Pod，并将所有网络请求转发给这些Pod。
除了提供稳定的对外访问方式，Service还具备负载均衡的功能，可以自动将请求流量分发到后端的所有Pod上。Service还能够实现透明的水平扩展，对客户端来说是无感知的。
实现Service功能的关键是kube-proxy。kube-proxy在每个节点上运行，监听API Server中服务对象的变化，并通过三种流量调度模式（userspace、iptables、ipvs）来实现网络转发。
Service是K8S服务的核心，它屏蔽了服务的细节，统一对外暴露服务接口，实现了真正的"微服务"。对于用户来说，只需要关注一个Service的入口，而不需要关心具体请求哪个Pod。
这样做的优势非常明显：外部用户不需要关注Pod意外崩溃或K8S重新创建Pod导致的IP变化，也不需要关注升级或变更服务导致的Pod替换和IP变化。

以下是一些关键的Service特性和概念：

ClusterIP：每个Service都有一个ClusterIP，它是Service在集群内部的虚拟IP地址。其他Pod或Service可以通过该IP地址与Service进行通信。
Service类型：Kubernetes支持多种Service类型，包括ClusterIP、NodePort、LoadBalancer和ExternalName。每种类型都有不同的用途和配置方式。
Selector：Service使用Selector来标识它所关联的Pod。通过标签选择器，Service可以将流量转发到具有特定标签的Pod上。
端口映射：Service可以将外部请求的端口映射到后端Pod的端口。这样，外部应用程序可以通过Service的IP地址和映射的端口与Pod进行通信。
Headless Service：除了普通的Service类型，Kubernetes还支持Headless Service。Headless Service不会分配ClusterIP，而是直接暴露后端Pod的网络地址。

Ingress

在Kubernetes集群中，Service主要负责集群内部的网络拓扑，它提供了一种抽象的方式来访问一组Pod。但是，如果要从集群外部访问集群内部的服务，就需要使用Ingress。
Ingress充当了整个Kubernetes集群的接入层，它负责处理集群内外的通信。作为第7层应用层的组件，Ingress可以通过HTTP/HTTPS等协议对外暴露服务。
与Service不同，Service只能进行第4层的流量调度，使用IP地址和端口进行访问。而Ingress可以根据不同的业务域和URL访问路径来调度业务流量。

用于将外部流量路由到集群内部的服务。它充当了集群和外部网络之间的入口点。

具体来说，Ingress定义了一组规则，用于将外部请求路由到集群内部的服务。它可以根据请求的主机名、路径或其他标识符将流量转发到相应的服务。通过使用Ingress，可以实现负载均衡、SSL终止、路径基础的路由等功能。
在使用Ingress之前，需要先部署一个Ingress控制器。Ingress控制器是一个运行在集群中的组件，负责监视Ingress资源的变化，并根据规则配置负载均衡器或代理服务器来处理外部流量。
一旦Ingress控制器部署好并配置了相应的规则，外部流量就可以通过Ingress路由到集群内部的服务。这样，可以通过一个统一的入口点来访问多个服务，而无需暴露每个服务的具体地址。

总之，Ingress是Kubernetes中用于管理外部流量访问的一种机制，它通过定义规则将外部请求路由到集群内部的服务，提供了更灵活和可扩展的流量管理方式。

Name

在Kubernetes中，每个资源都有自己的名称，通常定义在资源的元数据（metadata）中。元数据包含了一些描述资源的属性，其中包括名称（name）属性。

名称在同一个命名空间（namespace）中必须是唯一的，这意味着在同一个命名空间中不能存在相同名称的资源。这样可以确保在集群中对资源进行唯一标识和引用。

除了名称，元数据还可以包含其他属性，如标签（labels）和注释（annotations）。标签用于对资源进行分类和组织，而注释则是一些额外的描述性信息。

通过名称和其他元数据属性，可以在Kubernetes中对资源进行识别、查询和操作。这些属性在定义资源的清单文件或通过Kubernetes API进行编程时非常重要。

Namespace 命名空间

Namespace（命名空间），用于在集群中创建虚拟的工作环境，将资源进行隔离和分类。它可以帮助不同的团队或项目在同一个集群中共享资源，同时保持彼此之间的隔离。

使用Namespace可以将集群中的资源划分为逻辑上独立的单元，每个Namespace都有自己的资源配额、网络和存储资源。不同的Namespace可以拥有相同名称的资源，但它们彼此之间是隔离的，不会相互干扰。

Namespace的主要作用包括：

隔离和分类：通过将资源划分到不同的Namespace中，可以将不同的团队、项目或环境隔离开来，避免资源冲突和干扰。
访问控制：可以使用RBAC（Role-Based Access Control）等机制对不同的Namespace进行权限控制，限制用户或团队对资源的访问和操作。
资源配额：可以为每个Namespace设置资源配额，限制其使用的计算、存储和网络资源的数量，以避免资源被某个Namespace过度占用。
管理和监控：通过将资源按照Namespace进行分类，可以更方便地管理和监控集群中的资源使用情况，进行故障排查和性能优化。

在Kubernetes中，默认会创建一个名为"default"的Namespace，如果没有显式指定Namespace，资源将被分配到"default" Namespace中。除了"default" Namespace外，还可以创建自定义的Namespace，根据实际需求进行资源的划分和管理。

不同 Namespace 内的 “资源” 名称可以相同，相同 Namespace 内的同种 “资源”，“名称” 不能相同。合理的使用 K8S 的 Namespace，可以使得集群管理员能够更好的对交付到 K8S 里的服务进行分类管理和浏览。查询 K8S 里特定 “资源” 要带上相应的 Namespace。

K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 | 韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。长夜有穷，真水无香。领略过了 K8s“身在江

K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub