我们上一章介绍了Docker基本情况,目前在规模较大的容器集群基本都是Kubernetes,但是Kubernetes涉及的东西和概念确实是太多了,而且随着版本迭代功能在还增加,笔者有些功能也确实没用过,所以只能按照我自己的理解来讲解。
Kubernetes相关概念介绍
什么是 Kubernetes
Kubernetes 是一个用于自动化容器化应用程序部署、扩展和管理的开源平台。它提供了一种容器编排的方式,可以自动管理应用程序的部署、伸缩、负载均衡和容错等任务。 Kubernetes 基于容器技术,特别是 Docker,它使用容器作为应用程序和服务的基本构建块。通过 Kubernetes,用户可以轻松地定义和部署容器化应用程序,并通过集群来管理和编排这些容器。
Master
在 Kubernetes 中,Master 是控制平面的组件,负责管理和调度集群中的工作负载。Master 负责监控集群状态、调度 Pod、管理资源分配、处理集群级别的操作等。
Kubernetes 的 Master 组件包括以下几个核心组件:
-
API Server:作为集群的统一入口,提供 API 用于与集群交互,包括创建、删除和管理资源等操作。所有的 Kubernetes API 请求都通过 API Server 进行处理。其他组件不会相互通信,包括Node的组件都只和APL Server通信。
-
Controller Manager:负责管理和运行集群中的控制器。控制器用于监控集群的状态,并根据预期状态与实际状态的差异进行调整。例如,Replication Controller 负责确保 Pod 的副本数符合预期,Namespace Controller 负责管理命名空间等。
-
Scheduler:负责根据预定的策略将 Pod 分配到集群中的节点上。Scheduler 考虑诸如节点资源、Pod 的需求和亲和性/反亲和性规则等因素来进行调度决策,以实现负载均衡和高可用性。
-
Etcd:作为集群的数据存储,用于存储集群的配置信息、状态和元数据。etcd 是一个分布式、可靠且高度可用的键值存储系统,用于保证集群的一致性和持久性。
Master 组件通常运行在一个独立的节点上,该节点不会运行应用程序容器。它们共同协作,通过相互通信来管理和维护整个 Kubernetes 集群的状态。
Node
在 Kubernetes 中,Node(节点)是集群中运行容器化应用程序的工作节点。每个节点都是 Kubernetes 集群中的一台物理或虚拟机器,它负责运行和托管容器化的工作负载。
Node 上运行着以下几个核心组件:
-
Kubelet:是 Kubernetes Agent,负责与 Master 节点通信并管理 Node 上的容器操作。它监控和报告 Node 上的容器状态,执行容器的创建、启动、停止等操作。
-
Container Runtime:是负责运行容器的软件,如 Docker、containerd 等。它负责根据容器镜像创建和管理容器实例,并提供容器的隔离和资源管理。
-
Kube-Proxy:负责网络代理和负载均衡,处理集群内部和集群外部的网络流量转发。它维护了集群内部的网络规则和服务发现,使得容器能够相互通信和访问集群内外的服务。
每个 Node 都有一个唯一的标识符,称为 Node 名称。Node 的名称通常是根据主机的网络标识或者主机名来确定的。
Pod
在 Kubernetes 中,Pod(容器组)是最小的可调度和可部署的单元。它是一个逻辑概念,用于包装一个或多个相关的容器,并共享网络和存储资源。
Pod 中的容器紧密相关,并且它们一起协同工作来提供某种服务或应用程序。这些容器可以共享同一个网络命名空间和存储卷,它们可以通过 localhost 直接通信。
Pod 具有以下特点:
-
调度单元:Pod 是 Kubernetes 中最小的调度单元,调度器将一个 Pod 分配给一个可用的节点来运行。
-
共享网络和存储:Pod 中的容器共享同一个网络命名空间和存储卷。它们可以通过 localhost 直接通信,并共享数据。
-
生命周期:Pod 具有自己的生命周期,可以创建、启动、停止和删除。当 Pod 被删除时,它内部的所有容器也会被终止。
Pod 有以下几种常见的使用方式:
-
单容器 Pod:一个 Pod 中只包含一个容器,用于运行一个独立的应用程序服务。
-
多容器 Pod:一个 Pod 中包含多个紧密相关的容器,可以协同工作。例如,一个应用程序容器和一个辅助容器(如 Sidecar 容器)共同组成一个 Pod。
-
无状态 Pod:Pod 中的容器不需要保持任何状态,所有数据都来自外部存储(如数据库)或者共享数据卷。
-
有状态 Pod:Pod 中的容器需要保持一些状态,例如使用本地存储或者共享存储卷存储数据。
Deployment
在 Kubernetes 中,Deployment(部署)是一种资源对象,用于定义和管理容器化应用程序的部署和升级。Deployment 提供了一个声明式的方式来描述应用程序的期望状态,并负责确保实际状态与期望状态保持一致。
Deployment 定义了应用程序的副本数、容器镜像版本、资源要求和限制等信息,并通过控制 ReplicaSet 对象来创建和管理实际运行的 Pod 集合。Deployment 可以轻松地进行部署、扩展、回滚和升级操作,以满足应用程序的需求。
使用 Deployment 有以下优点:
-
无缝的部署更新:Deployment 支持滚动更新策略,可以逐步替换旧的 Pod 实例,实现应用程序的无缝升级,避免中断服务。
-
自动修复:如果某个 Pod 失败或被删除,Deployment 会自动创建一个新的 Pod 来代替,确保应用程序的高可用性。
-
水平扩展:可以通过简单地修改 Deployment 的副本数来实现应用程序的水平扩展,根据负载情况自动增加或减少 Pod 的数量。
-
回滚和版本管理:Deployment 支持回滚到之前的版本,可以轻松地管理和切换不同的应用程序版本。
-
监控和管理:Deployment 提供了许多监控和管理功能,如指标收集、日志查看和事件追踪等,方便运维人员进行应用程序的管理和故障排查。
ReplicaSet
在 Kubernetes 中,ReplicaSet(副本集)是一种资源对象,用于定义和管理 Pod 的副本数量。它可以确保在任何时候都有指定数量的 Pod 实例在运行,并且在 Pod 失败或被删除时能够自动创建新的 Pod 实例。
ReplicaSet 的主要功能是通过控制 Pod 的数量来实现高可用性和扩展性。它会根据用户指定的副本数创建并管理一组相同的 Pod,确保这些 Pod 在集群中的不同节点上均匀分布,并且在有 Pod 失效或被删除时自动创建新的 Pod 来替代。
ReplicaSet 具有以下特征:
-
副本数控制:ReplicaSet 可以定义所需的 Pod 副本数量,它会监控当前运行的 Pod 实例数,并在需要时自动创建或终止 Pod,以保持副本数的稳定。
-
选择器标签:ReplicaSet 使用选择器来标识所管理的 Pod。通过选择器,ReplicaSet 可以选择一组符合条件的 Pod,并对它们进行管理。
-
自动修复和水平扩展:当 Pod 失败或被删除时,ReplicaSet 会自动创建新的 Pod 来替代,以确保所需的副本数不变。此外,可以通过简单地修改 ReplicaSet 的副本数来实现应用程序的水平扩展,根据负载情况自动增加或减少 Pod 的数量。
-
版本管理:ReplicaSet 可以使用不同的 Pod 模板定义不同的版本,可以方便地进行应用程序的版本管理和回滚操作。
一般而言,我们不会单独配置ReplicaSet,而是使用Deployment来定义自己需要,而Deployment则是通过创建ReplicaSet来控制pod的更新,删除等操作。
DaemonSet
DaemonSet(守护进程集)是 Kubernetes 中的一种资源对象,用于在集群的每个节点上运行一个副本(Pod 实例)来保证某个特定的守护进程在每个节点上运行。
与 ReplicaSet 不同,它保证在每个节点上只运行一个 Pod 实例,而不是多个副本。DaemonSet 可以用于在每个节点上运行一些特定的系统级别的守护进程,例如日志收集器、监控代理、网络代理等。这些守护进程通常需要在每个节点上运行,并与该节点上运行的其他应用程序进行通信。
DaemonSet 具有以下特征:
-
在每个节点上运行一个副本:DaemonSet 确保在集群的每个节点上运行一个 Pod 实例,以保证守护进程在每个节点上都可用。
-
节点自动加入和退出:当新的节点加入集群或现有节点从集群中删除时,DaemonSet 会自动创建或删除相应的 Pod 实例,以保持每个节点上都有一个守护进程运行。
-
节点亲和性和调度约束:可以使用节点亲和性和调度约束来控制 DaemonSet 的 Pod 在哪些节点上运行。这样可以根据节点的特性或标签来选择合适的节点来运行守护进程。
-
守护进程的版本管理:可以使用更新的 DaemonSet 模板来定义新版本的守护进程,并进行滚动更新以保证每个节点上的守护进程都是最新版本。
StatefulSet
StatefulSet(有状态副本集)是 Kubernetes 的一种资源对象,用于管理有状态应用程序的副本数量和状态。
与 ReplicaSet 和 DaemonSet 不同,StatefulSet 专门用于管理有状态的应用程序,这些应用程序通常需要持久化存储和稳定的网络标识。StatefulSet 提供了一种机制来为有状态应用程序中的每个副本分配唯一的标识符,并在部署、扩展和终止副本时维护这些标识符的稳定性。
StatefulSet 具有以下特征:
-
有序部署和扩展:StatefulSet 保证每个 Pod 副本按照定义的顺序进行部署和扩展。这对于有依赖关系的应用程序非常重要,例如数据库的主从复制。
-
稳定的网络标识:每个 StatefulSet 的 Pod 都具有一个稳定的网络标识,可以通过其索引或名称进行访问。这对于有状态应用程序来说非常重要,因为它们通常需要通过特定的名称或标识来进行通信。
-
持久化存储卷:StatefulSet 可以指定要为每个 Pod 副本使用的持久化存储卷,以确保数据在 Pod 重启或重新创建时不会丢失。
-
有状态服务:StatefulSet 还可以自动创建与其关联的有状态服务,以便在集群内部可以通过服务名称进行网络访问。
Ingress
Ingress 是 Kubernetes 中的一种资源对象,用于将外部流量路由到集群内部的服务。
在 Kubernetes 中,每个服务都有一个 ClusterIP,该 IP 只能在集群内部访问。然而,有时我们希望将服务暴露给集群外部的流量,这就是 Ingress 的作用。
Ingress 具有以下特点:
-
路由规则:Ingress 允许定义路由规则来将外部流量路由到集群内部的不同服务。这些规则通常基于主机名、路径或请求头等标准来进行匹配和转发。
-
SSL/TLS 加密:Ingress 支持通过 TLS 密钥和证书来加密外部流量。这可以确保外部流量在传输过程中的安全性。
-
负载均衡:Ingress 可以与负载均衡器配合使用,以便将外部流量均匀地分发到后端服务的多个副本上,以提高可用性和性能。
-
路径重写:Ingress 可以支持在将流量转发到后端服务之前,对路径进行重写或替换,以便将请求转发到不同的路径上。
需要注意的是,Ingress 只是定义了路由规则和配置选项,并不实际处理流量转发。为了使 Ingress 生效,需要在集群中运行一个 Ingress Controller,它会根据 Ingress 的定义来配置负载均衡器或代理服务器,并将流量转发到相应的后端服务。
ConfigMap
ConfigMap(配置映射)是 Kubernetes 中的一种资源对象,用于将配置数据从应用程序的容器中分离出来,并使其可配置化。
在 Kubernetes 中,容器镜像通常包含应用程序的代码和配置文件。然而,将配置硬编码在容器镜像中会使得配置更加困难,因为每次更改配置都需要重新构建和部署容器镜像。而使用 ConfigMap 可以将配置数据与容器镜像分离,使配置更加灵活和可配置化。
ConfigMap 具有以下特点:
-
键值对数据:ConfigMap 由一组键值对数据组成,可以包含任何应用程序所需的配置信息,如环境变量、命令行参数、配置文件等。
-
独立于容器镜像:ConfigMap 可以在容器镜像之外创建和管理,使得配置可以独立于容器镜像进行更改和调整。
-
挂载到容器:ConfigMap 可以通过卷挂载的方式,将配置数据注入到容器中,以便应用程序可以读取和使用这些配置。
-
动态刷新:当 ConfigMap 的数据发生更改时,可以通过重启容器或使用特定的工具来刷新容器中的配置,而无需重新构建和部署容器镜像。
使用 ConfigMap 可以使得应用程序的配置更加灵活和可配置化,同时也方便了配置的管理和更新。通过将配置数据与容器镜像分离,可以更好地实现配置的可持续性和灵活性。
最常用的用法,是把应用的配置文件存储在ConfigMap。
Secret
Secret(秘密)是 Kubernetes 中的一种资源对象,用于存储和管理敏感信息,如密码、密钥、证书等。
在应用程序中,通常需要使用敏感信息来访问其他服务、数据库或进行加密通信。为了保护这些敏感信息的安全性,Kubernetes 提供了 Secret 对象,用于安全地存储和传递这些敏感信息。
Secret 具有以下特点:
-
类型和数据:Secret 可以存储多种类型的敏感信息,如字符串、Base64 编码的数据、Docker 镜像私有仓库的认证信息等。数据存储在 Secret 中时会被加密,确保在存储和传输过程中的安全性。
-
挂载到容器:Secret 可以通过卷挂载的方式,将敏感信息注入到容器中,以便应用程序可以读取和使用这些信息。这样可以避免将敏感信息硬编码在容器镜像中,增加了安全性。
-
限制访问权限:Secret 可以通过 Kubernetes 的访问控制机制,限制对敏感信息的访问权限,确保只有授权的实体可以访问和使用 Secret 中的数据。
-
动态更新:当需要更改敏感信息时,可以直接更新 Secret 对象,而无需重新构建和部署容器镜像。这样可以方便地进行敏感信息的管理和更新。
使用 Secret 可以保护敏感信息的安全性,避免将它们明文存储在容器镜像或配置文件中。通过将敏感信息存储在加密的 Secret 中,并通过挂载到容器的方式进行访问,可以提高应用程序的安全性。
这个最常用的做法是把下载镜像需要登陆的信息放置到secret里面,确保控制器可以登陆镜像仓库下载镜像
PersistentVolume
PersistentVolume(持久化卷)是 Kubernetes 中的一种资源对象,用于提供持久化存储给应用程序使用。
在 Kubernetes 中,容器是临时性的,当容器被删除或重启时,容器内的数据也会丢失。为了解决这个问题,Kubernetes 提供了 PersistentVolume 对象,用于将持久化存储资源抽象出来,使得容器可以访问并使用这些持久化存储。
PersistentVolume 具有以下特点:
-
独立于容器:PersistentVolume 是集群级别的资源,独立于任何特定的 Pod 或容器。这意味着 PersistentVolume 可以在多个 Pod 之间共享,并且不会受到 Pod 的生命周期影响。
-
提供持久化存储:PersistentVolume 可以与各种存储后端进行绑定,如本地磁盘、网络存储、云存储等。这样,应用程序可以通过挂载 PersistentVolume 到容器中,来访问和使用持久化存储。
-
动态和静态分配:PersistentVolume 可以静态或动态地分配给应用程序。静态分配是手动创建 PersistentVolume,并在需要时手动绑定到 Pod。而动态分配是通过使用 StorageClass 对象,自动创建和绑定 PersistentVolume。
-
存储策略:PersistentVolume 支持多种存储策略,如读写一致性、只读、多访问模式等。这样可以根据应用程序的需求选择适当的存储策略。
使用 PersistentVolume 可以为应用程序提供持久化存储,使得容器可以在重启或迁移后继续访问和使用之前的数据。通过将 PersistentVolume 挂载到容器中,应用程序可以像访问本地磁盘一样访问持久化存储,从而实现数据的持久化和可靠性。
PersistentVolumeClaim
PersistentVolumeClaim(持久化卷声明)是 Kubernetes 中的一种资源对象,用于声明对持久化存储资源的需求。
在 Kubernetes 中,应用程序需要持久化存储来存储和访问数据。为了使用持久化存储资源,应用程序需要创建一个 PersistentVolumeClaim 对象,来声明对持久化卷的需求。
PersistentVolumeClaim 具有以下特点:
-
针对持久化卷:PersistentVolumeClaim 是与 PersistentVolume 对象配合使用的。它声明了对持久化卷的需求,以便 Kubernetes 可以为应用程序提供适当的持久化存储资源。
-
存储类别:PersistentVolumeClaim 可以指定所需的存储类别。存储类别是一种抽象,它定义了具体的存储后端和存储策略,如本地磁盘、网络存储、云存储等。通过指定存储类别,应用程序可以请求特定类型的持久化存储。
-
访问模式:PersistentVolumeClaim 可以指定所需的访问模式,如读写一致性、只读、多访问模式等。这样可以根据应用程序的需求选择适当的访问模式。
-
动态分配:PersistentVolumeClaim 也支持动态分配持久化卷。当创建一个 PersistentVolumeClaim 对象时,Kubernetes 可以根据存储类别和其他配置信息,自动创建和绑定一个符合要求的 PersistentVolume。
通过创建 PersistentVolumeClaim 对象,应用程序可以声明对持久化存储资源的需求,并与 PersistentVolume 对象进行绑定。这样,Kubernetes 可以根据需求和可用的存储资源,为应用程序提供所需的持久化存储。
Service
在Kubernetes中,Service(服务)是一种资源对象,用于定义一组Pod的访问方式和网络规则。
Service具有以下特点:
-
提供稳定的访问地址:Service为一组Pod提供了一个稳定的虚拟IP地址,该地址可以作为入口点用于访问这些Pod。这样,无论Pod的IP地址如何变化,应用程序都可以通过Service来访问它们。
-
负载均衡:Service可以将流量均匀地分发到后端Pod实例中,以实现负载均衡。这样可以确保每个Pod获得相对均匀的请求负载,提高应用程序的可扩展性和性能。
-
服务发现:Service充当了一种服务发现的机制,它通过自动识别和注册后端Pod实例的变化,确保新的Pod实例可以动态地加入到Service的访问范围内,而无需手动配置。
-
通信协议:Service支持不同的通信协议,如TCP和UDP。这样可以根据应用程序的需求选择适当的协议。
-
内部和外部访问:Service可以配置为仅在集群内部可访问,也可以通过公共IP地址或负载均衡器暴露给外部用户。这样,可以根据应用程序的需求控制服务的可见性和访问权限。
通过创建Service对象,可以为一组Pod定义一个稳定的访问入口,并提供负载均衡和服务发现的功能。应用程序可以通过访问Service的虚拟IP地址来与后端的Pod进行通信,而无需关心Pod的具体IP地址和变化。
Namespace
在 Kubernetes 中,Namespace(命名空间)是一种将集群资源进行逻辑划分的机制,它使得多个团队或多个项目可以共享同一个集群,而不会互相干扰。Namespace 是对一组资源和对象的抽象集合,常用于多租户环境中,它提供了一定级别的隔离和组织方式。
基本用途
-
资源隔离:Namespace 提供了一种隔离机制,使得不同的项目、团队或客户可以在同一个集群中运行,而不会相互干扰。
-
权限控制:可以通过角色访问控制(Role-Based Access Control,RBAC)对不同 Namespace 中的资源进行细粒度的权限管理。
-
资源配额:通过设置 Namespace 级别的资源配额(ResourceQuota),管理员可以限制每个 Namespace 可以消耗的资源数量,确保资源按需分配。
当然Kubernetes中涉及的概念还有很多,这里只列举了一部分,让你对k8s有一定的理解。
运维小路
一个不会开发的运维!一个要学开发的运维!一个学不会开发的运维!欢迎大家骚扰的运维!
关注微信公众号《运维小路》获取更多内容。