Kubernetes 简介

• K8s是可移植、可扩展、开源的容器管理平台，简称K8s：
• 可移植：可从一个环境迁移到另一个环境
• 可扩展：K8s集群可以横向扩展、根据流量使用实现扩缩容
• 开源的：源代码已经公开了，可以被用户免费使用
• 可以对容器自动化部署、自动化扩缩容、跨主机管理等；
• 可以对代码进行灰度发布、金丝雀发布、蓝绿发布、滚动更新等；
• 具有完整的监控系统和日志收集平台，具有故障自恢复的能力。

来源于Google的 Borg项目：
Borg是谷歌内部的一个容器编排工具，谷歌业务90%以上都在Borg上运行，Borg在谷歌内部已经使用了大概15年。 K8s是在Borg的基础上开发出来的轻量级容器编排工具。K8s的根基非常牢固，得益于Borg过去十数年间积累的经验和教训，是站在巨人的肩膀上发展起来的项目。开源之后，迅速称霸容器编排技术领域。

架构

• K8s的物理架构是master/node模式：
• K8s集群至少需要一个主节点(Master)和多个工作节点(Worker)，Master节点是集群的控制节点，负责整个集群的管理和控制，主节点主要用于暴露API，调度部署和节点的管理。工作节点主要是运行容器的。
• master节点: apiserver，controller-manager，scheduler，etcd
• node节点：kubelet，kube-proxy

多master节点架构图

功能

控制节点组件

apiserver

• 作用：API Server 是 Kubernetes 控制平面的核心组件，它作为所有用户请求的入口，负责接收和处理外部请求（如 kubectl 命令）以及集群内各组件的内部请求。API Server 提供 RESTful API 接口，供用户和 Kubernetes 控制平面的其他组件交互。
• 工作原理：API Server 将请求验证、认证，并根据请求类型（如 GET、POST、PUT 等）与 Etcd 存储交互。它还会通过授权（RBAC）和准入控制器（Admission Controller）来确保请求符合权限和策略。

etcd

• 作用：Etcd 是一个分布式键值存储，用于存储 Kubernetes 集群的所有配置信息和状态数据（如集群配置、Pod 状态、节点信息等）。
• 工作原理：Etcd 通过强一致性保证集群数据的一致性。Kubernetes 中的所有状态信息（如 Pod、Service、ConfigMap、Secret 等）都会存储在 Etcd 中，它支持数据的高可用性和灾难恢复。

scheduler

• 作用：Scheduler 负责将没有指定节点的 Pod 调度到适当的节点上。它会根据资源需求、亲和性、反亲和性、污点和容忍等规则来做出调度决策。
• 工作原理：Scheduler 从 API Server 获取待调度的 Pod 列表，并根据集群中各节点的资源状况（如 CPU、内存、磁盘等）决定将 Pod 安排在哪个节点上。它会考虑节点的负载、约束条件（如节点选择器、亲和性等）以及其他调度策略。

controller-manager

• 作用：Controller Manager 运行控制器，负责 Kubernetes 集群状态的维护。控制器是一个循环控制系统，确保集群中的实际状态符合期望状态。

• 工作原理：Controller Manager 包含多个控制器（如 Replication Controller、Deployment Controller、StatefulSet Controller 等），每个控制器监视集群的某个方面，并确保系统状态始终保持一致。例如，Deployment Controller 会确保部署的 Pod 数量与期望的副本数一致，Pod 的健康检查失败时会自动重新创建 Pod。

• calico:提供网络插件，网络策略隔离

• coredns:k8s里的域名解析到对应IP

工作节点组件

Kubelet

• 作用：Kubelet 是 Kubernetes 中每个节点上的代理，它负责管理节点上的容器，并确保容器在节点上正常运行。
• 工作原理：Kubelet 会定期向 API Server 汇报节点和容器的状态，并且确保本地的 Pod 和容器与 API Server 中的期望状态一致。如果容器崩溃或需要重新启动，Kubelet 会处理容器的启动和重启。

kube-proxy

• 功能： 提供网络代理和负载均衡，是实现服务（Service）的通信与负载均衡机制的重要组件。
• 位置： 运行在每个节点上
• 任务：
  • 维护节点上的网络规则，以支持服务发现和负载均衡。
  • 通过在节点上创建虚拟IP和端口转发来提供服务访问
• 实现机制：
  • 从 Kubernetes API Server 获取所有服务信息。
  • 根据服务信息创建代理服务，建立服务到 Pod 的请求路由和转发。
  • 将服务的 IP 地址写入 iptables 或者 ipvs 规则中。
• 效果： 实现了 Kubernetes 层级的虚拟转发网络，确保将到服务的请求转发到后端的 Pod 上。
• 关键作用：
  • 为服务提供代理，实现服务间的通信。
  • 在节点上创建网络规则，支持服务发现和负载均衡。

Ingress Controller

• 作用：Ingress Controller 是负责处理集群外部 HTTP 和 HTTPS 流量的组件。它基于 Ingress 资源，提供 HTTP 路由、SSL/TLS 终端等功能。
• 工作原理：Ingress 资源定义了外部访问服务的规则，而 Ingress Controller 会根据这些规则配置外部访问的路由和负载均衡。它允许将多个服务暴露在同一个负载均衡器上，并根据请求的路径或主机名将流量转发到不同的后端服务。

Namespace

• 作用：Namespace 是 Kubernetes 中的一种资源隔离机制，允许在同一个集群中创建多个虚拟集群。每个命名空间内的资源（如 Pod、Service、ConfigMap 等）是独立的。
• 工作原理：命名空间用于组织集群中的资源，并在大规模集群中提供隔离。在多租户环境中，不同的团队或项目可以在各自的命名空间中管理资源，从而避免资源冲突。

Volume

• 作用：Volume 是 Kubernetes 提供的一种持久化存储解决方案，容器内的数据可以存储在 Volume 中，以便容器重启或迁移后数据仍然可用。
• 工作原理：Volume 是与 Pod 生命周期绑定的，可以挂载到 Pod 中的容器上。Kubernetes 支持多种类型的 Volume（如 HostPath、NFS、Ceph、Cloud Provider 的存储服务等），并且通过 Persistent Volume（PV）和 Persistent Volume Claim（PVC）来动态管理存储资源。

Service

• 作用：Service 是 Kubernetes 中的一个抽象层，用于定义一组 Pod 的访问方式，通常是通过负载均衡器来提供稳定的网络访问。
• 工作原理：Service 提供了一种访问 Pod 的方法，它会自动发现并负载均衡所有后端 Pod 的流量。通过 ClusterIP、NodePort、LoadBalancer 等不同类型的 Service，用户可以定义不同的访问方式和策略。

ConfigMap

• 作用：ConfigMap 和 Secret 是用于管理应用程序配置和敏感信息的资源对象。ConfigMap 存储非敏感的配置信息，而 Secret 存储机密信息，如数据库密码、API 密钥等。
• 工作原理：ConfigMap 和 Secret 允许在容器中以环境变量、命令行参数或挂载文件的方式提供配置信息。这些信息可以在 Pod 中以动态的方式进行更新，从而减少应用程序的硬编码配置。

Container Runtime

• Container Runtime： Container Runtime是负责运行容器的软件。Kubernetes支持多种容器运行时，包括Docker、containerd、CRI-O等。kubelet与容器运行时进行通信，以启动和管理容器

CNI插件

• CNI插件（Container Network Interface）： CNI插件负责为Pod创建和配置网络。它定义了如何在容器之间建立网络连接以及如何为Pod分配IP地址。

Calico

Calico 是一个强大的网络插件，支持高性能的容器网络、网络策略和多云环境。

特点：

• 网络策略：Calico 是 Kubernetes 中最流行的 CNI 插件之一，提供强大的 网络策略，可以对流量进行细粒度控制，包括 Ingress 和 Egress 策略。
• 支持 BGP 路由：Calico 使用 BGP 协议来提供跨节点的路由信息，它也支持 IP-in-IP 模式来封装流量。
• 性能优越：Calico 直接使用 Linux 内核的路由功能，提供非常高的性能。
• 支持网络隔离：通过 NetworkPolicy，可以对不同的应用和租户进行流量控制和隔离。

优点：

• 提供高性能，适用于大规模生产环境。
• 提供完整的网络策略功能，支持跨云环境和混合云。
• 高度可定制化，支持多种后端（BGP、VXLAN、IP-in-IP）。

缺点：

• 配置和维护相对复杂。
• 对某些环境可能需要额外的网络硬件支持（如 BGP 路由）。

资源对象

• Pod 是Kubernetes中的最小调度单元，当指派容器时，容器实际上并不会指派到物理硬件上，容器会被分配到一个Pod里。Pod代表集群上正在运行的一个进程，一个Pod封装一个容器（也可以封装多个容器），Pod里的容器共享存储、网络等。也就是说，应该把整个pod看作虚拟机，然后每个容器相当于运行在虚拟机的进程。
• Replicaset：用于确保指定副本数的 Pod 始终在运行，但支持更灵活的标签选择器（不常用，基本使用Deployment）
• Deployment管理Replicaset和Pod的副本控制器，Deployment可以管理多个Replicaset，是比Replicaset更高级的控制器，也即是说在创建Deployment的时候，会自动创建Replicaset，由Replicaset再创建Pod，Deployment能对Pod扩容、缩容、滚动更新和回滚、维持Pod数量。

• Statefulset：用于维护有状态应用，确保 Pod 在集群中的唯一标识和持久性存储。

• DaemonSet:用于确保在集群中的每个节点上运行一个 Pod 的副本，通常用于部署节点级别的服务。

• Job & CronJob：用于运行一次性任务或批处理作业，确保任务成功完成
  用于定期运行任务，类似于 Linux 中的 cron 任务。

• Service：不是直接控制器，但是用于提供 Pod 的网络服务，具有负载均衡和服务发现的功能。
  在kubernetes中，Pod是有生命周期的，如果Pod重启IP很有可能会发生变化。如果我们的服务都是将Pod的IP地址写死，Pod的挂掉或者重启，和刚才重启的pod相关联的其他服务将会找不到它所关联的Pod，为了解决这个问题，在kubernetes中定义了service资源对象，Service 定义了一个服务访问的入口，客户端通过这个入口即可访问服务背后的应用集群实例，service是一组Pod的逻辑集合，这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector实现的。
  

• Ingress ：维护七层代理的

• Configmap和Secret ：配置管理中心

kubelet、kubeadm 和 kubectl 各自有的职责和功能。

• kubelet 是运行在每个 Kubernetes 节点上的代理，负责管理该节点上的容器。它与容器运行时通信，确保容器按照 Pod 的规格运行。kubelet 还负责监控容器的状态，并向主控制平面报告节点的状态。
• kubeadm 是 Kubernetes 的一个命令行工具，用于在一个或多个节点上启动、初始化或升级 Kubernetes 集群。它提供了一个简化的方式来配置集群，而不必手动执行复杂的步骤。kubeadm 通常用于设置和管理集群的初始化过程。
• kubectl 是 Kubernetes 的命令行客户端工具，用于与 Kubernetes 集群进行交互。通过 kubectl，用户可以管理集群、部署和扩展应用、查看集群状态等。kubectl 可以用来执行各种操作，例如创建、删除和更新资源对象（如 Pod、Service、Deployment 等）。

传统部署和K8S部署区别

基于K8s构建DevOps流程图

开发代码->提交代码到代码仓库->Jenkins调K8s API->动态生成Jenkins Slave Pod->Slave Pod拉取git上的代码->编译代码->打包镜像->推送镜像到镜像仓库harbor或者docker hub->通过K8s编排服务发布到测试、生产平台-> Slave Pod工作完成之后自动删除>通过Ingress发布服务。

Docker和Containerd对比分析

• 如果你使用Docker作为K8S容器运行时的话，kubelet需要先要通过dockershim去调用Docker，再通过Docker去调用containerd。
• 如果你使用containerd作为K8S容器运行时的话， kubelet可以直接调用containerd。

使用containerd不仅性能提高了（调用链变短了），而且资源占用也会变小（Docker不是一个纯粹的容器运行时，具有大量其他功能）。

调用链
Docker 作为 k8s 容器运行时，调用关系如下：
kubelet --> docker shim （在 kubelet 进程中） --> dockerd --> containerd

Containerd 作为 k8s 容器运行时，调用关系如下：
kubelet --> cri plugin（在 containerd 进程中） --> containerd