资源方针

Kubernetes 遵循 RESTful 风格办理其 API 资源方针，支撑经过标准的 HTTP 方法，POST、PUT、PATCH、DELETE、GET对资源进行增删改查等操作。Kubernetes 的 API 方针总的来说能够分为以下几类：作业负载、服务发现、负载均衡、装备和存储、集群、元数据。他们都是围绕 pod 而规划的，能够让运用者更好地运转和运用 pod 资源，然后完成容器化运用供给更灵敏和更完善的操作和办理组件。

作业负载型资源是保证 pod 资源更好的运转容器化运用。同一种负载的各种 pod 需求运用负载均衡的方法对外供给服务，而个容器化运用需求相互发现来完成作业。pod 资源有这完好的生命周期，存储型资源能够为重构的 pod 资源供给持久化数据存储，装备型资源能够让共享一致装备的 pod 从中经过获取装备信息（可动态装备）。这些资源作为装备中心为办理容器化运用的装备文件供给了极为便利的办理机制。集群型资源为办理集群本身的作业特性供给了装备接口，而元数据资源用于装备集群内部其他资源的行为。

Kubernetes中首要的资源方针

作业负载：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和内存等体系等级资源的数量约束等。