Kubernetes中主要的资源对象

资源对象

Kubernetes 遵循 RESTful 风格管理其 API 资源对象，支持通过标准的 HTTP 方法，POST、PUT、PATCH、DELETE、GET对资源进行增删改查等操作。Kubernetes 的 API 对象总的来说可以分为以下几类：工作负载、服务发现、负载均衡、配置和存储、集群、元数据。他们都是围绕 pod 而设计的，能够让使用者更好地运行和使用 pod 资源，从而实现容器化应用提供更灵活和更完善的操作和管理组件。

工作负载型资源是确保 pod 资源更好的运行容器化应用。同一种负载的各种 pod 需要使用负载均衡的方式对外提供服务，而个容器化应用需要相互发现来完成工作。pod 资源有这完整的生命周期，存储型资源能够为重构的 pod 资源提供持久化数据存储，配置型资源能够让共享统一配置的 pod 从中通过获取配置信息（可动态配置）。这些资源作为配置中心为管理容器化应用的配置文件提供了极为方便的管理机制。集群型资源为管理集群本身的工作特性提供了配置接口，而元数据资源用于配置集群内部其他资源的行为。

k8s-resources-object.jpg

工作负载：Pod

pod 承担这容器化应用，代表着 pod 是整个 Kubernetes 集群主要干活的那个资源，我们称为工作负载。pod 负责运行容器，为容器解决环境型的依赖，例如向容器注入临时或持久化的存储空间、配置信息或密钥等。诸如滚动更新、扩缩容等编排工作则是由控制器来负责，专门用于 pod 编排任务的控制器可以统称为 pod 控制器。

一般应用可以分为 有状态 和 无状态。无状态的应用中，每个 pod 都可以被其他同类示例取代，但是有状态的应用的 pod 实例均有其独特性，必须单独标识和管理。例如：ReplicationController、ReplicaSet和Deployment一般用来管理无状态应用，StatefulSet则用来管理有状态的应用。还有需要在集群每个节点上运行单个 pod 资源，例如负责收集日志等系统任务，一般我们都会把这些用DaemonSet控制器来管理。而需要再正常完成后退出，无需时刻处于运行状态的编排工作则是使用CronJob控制器来完成，而且还能为 Job 资源对象提供定期执行机制。

  • ReplicationController：用于确保每个 pod 副本在任一时刻都能满足目标数量，确保每个容器或者容器组总是运行并且可以访问。是上一代的无状态 pod 应用管理器。现在已经不再使用了，建议是使用 Deployment 和 ReplicaSet 来替代。

  • ReplicaSet：新一代的 ReplicationController，它与 ReplicationController 不一样的是在于支持的标签选择器不同，ReplicationController 只支持等值选择器，而 ReplicaSet 还支持基于集合的选择器。

  • Deployment：用于管理无状态的持久应用。例如提供HTTP服务的应用，也是最常见的应用。Deployment 用于为 pod 和 ReplicaSet 提供声明式更新，是构建在 ReplicaSet 之上的高级控制器。

  • StatefulSet：用于管理有状态的持久化应用，例如MySQL、Mongodb、Redis等。与 Deployment 不一样的在于 StatefulSet 会为每个 pod 创建一个独特的持久性标识符，并确保 pod 间的顺序性。

  • DaemonSet：确保每个节点都运行了某 pod 的一个副本，包括后来新增的节点。当节点被移除会将 pod 回收。DaemonSet 常用语运行各类系统级守护进程，如 kube-proxy、网络插件以及日志收集。

  • Job：用于管理运行完成后就可以终止的应用。例如批处理任务，Job 创建一个或多个 pod ，并确保符合目标数量，直到应用完成而终止。

服务发现和负载均衡

Service

Kubernetes 在设计支出就充分考虑了针对容器的服务发现和负载均衡，提供了 Service 资源。Service 是对一组提供相同功能的 pod 的抽象，并未他们提供一个统一的入口。通过 Service 应用可以方便地实现服务发现与负载均衡。Service 通过标签选择器来关联 pod。Service 主要有三种类型：

  • ClusterIP：默认类型，自动分配一个仅 Cluster 内可以访问的虚拟IP

  • NodePort：在 ClusterIP 的基础上为 Service 在每台机器上绑定一个端口，这样可以通过 NodeIP:NodePort 来访问服务

  • LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部的负载均衡器，并将请求转发到 NodeIP:NodePort

Ingress Controller

Service 虽然能够解决服务发现和负载均衡的问题，但在使用上还是限制，例如对外访问的时候，NodePort 类型需要在外部搭建额外的负载均衡，而 LoadBalancer 要求 Kubernetes 必须跑在支持的 cloud provider 上面。

Ingress 就是解决这些限制引入的新资源，主要用来将服务暴露到 Cluster 外面，并且可以自定义服务的访问策略。例如通过负载均衡器实现不同域名访问到不同的服务。而且 Ingress 是七层负载均衡的。

配置和存储

配置文件和数据存储的问题，需要了解一下容器的持久化存储。这里以 Docker 为例。Docker 容器分层联合挂载的方式决定了其文件系统文件无法在容器内存储持久化的数据。所以容器引擎引入外部存储卷来解决这个问题。

存储

在 Kubernetes 支持在 pod 配置外部存储卷资源Volume来为容器添加可用的外部存储。支持很多类型的存储设备或存储系统，例如：ClusterFS、Ceph RDB和Flocker等，还可以通过 FlexVolume 以及 CSI(Container Storage Interface)存储接口扩展支持更多类型的存储系统。

配置

在运行容器用用时，配置信息可以在制作镜像的时候以硬编码的形式置入，所以很难在不同的环境定制所需的配置。Docker 使用环境变量等作为解决方案，但需要在容器启动的时候将配置作为变量传入，且无法在运行的时候动态修改环境变量的值。Kubernetes 的 ConfigMap 资源能够以环境变量或者存储卷的方式接入到 pod 里面的容器，并且可以被多个同类的 pod 共享。不过 ConfigMap 不适合存储敏感资源，例如证书、密钥和密码等敏感信息，一般这些数据，我们会使用 Secret 资源来存储。

Kubernetes 1.24版本开始不再使用Docker，而是直接与 containerd 交互。而 Docker 又是对 containerd 的封装，基本功能都是 containerd 实现的。Kubernetes 与Docker 交互还需要额外维护一个 docker-shim 项目。所以现在直接使用 containerd 的话会更加地高效。虽然 Kubernetes 的容器运行时不在依赖 Docker，但是通过 Docker 构建出来的镜像还是可以在 Kubernetes 集群上使用的。所以在平时开发可以使用 Docker 构建或测试镜像和容器。

集群型资源

  • Namespace：命名空间，为资源对象的名称提供限定条件或者作用范围，为使用同一集群的团队或项目提供了逻辑上的隔离机制。

  • Node：Kubernetes 不能直接管理其他工作节点，它会把管理员加进来的任何形式的工作节点映射成一个 Node 资源对象，因此在同一个集群内节点名称必须唯一。

  • Role：隶属于命名空间，代表命名空间级别由规则组成的权限集合，可以被 RoleBinding 引用。

  • ClusterRole：集群角色，隶属于集群，代表集群级别的、由规则组成的权限集合，可以被 RoleBinding 和 ClusterRoleBinding 引用。

  • RoleBinding：用于将 Role 中的许可权限绑定在一个或一组租户，从而完成用户授权，它隶属于且仅能作用于命名空间级别。

  • ClusterRoleBinding：将 ClusterRole 中定义的许可权限绑定在一个或一组租户，通过引用全局命名空间中的 CluterRole 将集群级别的权限授予指定用户。

元数据型资源

元数据资源用于为集群内部的其他资源对象配置其行为或特性，例如：用于控制自动伸缩工作负载类型资源对象的规模，Pod 模板提供了创建 Pod 对象的预制模板，LimitRange 可以为命名空间内的 Pod 应用设置其CPU和内存等系统级别资源的数量限制等。