Kubernetes(6)-资源管理基础

Kubernetes 集群系统的 API Server 基于 HTTP/HTTPS 接收并相应客户端的操作请求，其提供了
基于资源(resourced-based)的 RESTful 风格的编程接口，将集群的各种组件都抽象为标准的 REST
资源，并支持通过标准的 HTTP 方法以 json 格式为数据序列化方法进行资源管理操作。

一. 资源对象及 API 群组

Kubernetes 系统将一切事物都抽象为 API 资源，其遵循 REST 架构风格组织并管理这些资源对象，
使用标准的 HTTP 方法(POST,PUT,PATCH,DELETE 和 GET)对资源进行增、删、改和查。需要区分
的是，在 Kubernetes 系统的语境中，资源代表了对象的集合，例如：Pod 资源可用于描述所有 Pod
类型的对象。对象实质是资源类型生成的实例。

1.1 Kubernetes 的资源对象

从资源的主要功能上可以把 Kubernetes 的资源对象分为：Workloads(工作负载)、
Service,LoadBalancing and Networking(服务发现和负载均衡)、存储和配置(Storage&Configuration)、
Cluster Admin(集群管理)、Policies&Scheduling(策略和调度)和 Metadata(元数据)。
设计这些资源的核心目的就是：如何更好的运行和管理 Pod 资源，为容器化应用提供更灵活、
更完善的操作与管理组件。

1.1.1 Workloads 类资源

• ReplicationController
  第一代的无状态 Pod 应用控制器，用于保证容器总是运行并且可访问
• ReplicaSet
  替代上一代控制器，支持基于集合的 Selector，而 ReplicationController 的 selector 只支持
  等值选择
• Deployment
  用于管理无状态的持久化应用(如 HTTP 服务器)，是构建在 ReplicaSet 上的更高级的控制器，使用
  该控制器实质是调用了 ReplicaSet 控制器
• StatefulSet
  用于管理有状态的持久化应用，如 database 服务，StatefulSet 会为每个 pod 创建一个独有的
  持久性标识符，并确保 pod 之间的顺序性
• DaemonSet
  常用于运行集群守护进程(glusterd,ceph)，日志收集进程(flunentd，logstash)和监控进程(Prometheus)
• Job
  用于创建运行完成后即可终止的应用

1.1.2 Service&Loadbalancing&Networking

• Service
  https://kubernetes.io/zh/docs/concepts/services-networking/service/

• EndPoint
  https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/

1.1.3 Configuration&Storage

• Volume 资源
  Volume 资源用来挂载外部存储卷，支持众多的存储设备或存储系统
• ConfigMap 资源
  ConfigMap 资源能以环境变量或者存储卷的方式接入到 pod 资源的容器中，并且可以被多个同类型
  的 pod 共享引用
• Secret 资源
  Secret 资源用来存储私钥、密码等敏感数据

1.1.4 集群级别的资源

• Namespace
  绝大多数对象都隶属于某个名称空间，默认时隶属于 default 名称空间
• Node
  Kubernetes 集群的工作节点，其标识符在当前集群中必须是唯一的
• Role
  名称空间级别的规则组成的权限的集合，可被 RoleBinding 引用
• ClusterRole
  集群级别的规则组成的权限集合，可被 RoleBinding 和 ClusterRoleBinding 引用
• RoleBinding
  将 Role 中的许可权限绑定在一个或一组用户之上
• ClusterRoleBinding
  将 ClusterRole 中定义的许可权限绑定在一个或一组用户之上

1.1.5 其他资源对象

• HorizontalPodAutoscaler：HPA，其可用于自动伸缩工作负载类型的资源对象的规模
• Pod 模板资源：可用于为 pod 资源的创建预备模板
• LimitRange 资源：可以为名称空间的资源设置其 CPU 和内存等系统资源的限制

1.2 资源及其在 API 中的组织形式

Kubernetes 利用标准的 RESTful 术语来描述其 API 概念。

• 资源类型：是指在 URL 中使用的名称，如 Pod、Namespace 和 Service 等，其 URL 格式为
  “GROUP/VERSION/RESOURCE”，如实际使用的：/apps/v1/deployment
• 所有资源类型都有一个对应的 JSON 表示格式：kind(种类)，在 K8s 中用户创建对象必须以 JSON
  格式提交对象的配置信息。
• 隶属于同一资源类型的对象组成的列表称为 collection(集合)，如 PodList
• 某种类型的单个实例称为"resource"(资源)或"object"(对象)，如运行的名为 stevie’s pod 的 Pod 对象

kind 代表了资源对象所属的类型，如 Namespace、Deployment、Service 等类型，这些类型又可以
分为三个类别：

• Object 类：对象表示 K8s 系统上的持久化实体，Namespace、Deployment、Service 和 Pod 都属于该类别
• List 列表类：列表是指同一类型资源的集合，如 PodList、NodeList 等。
• Simple 简单类：常用于子啊对象上执行某种特殊操作，或者管理非持久的实体，如/binding 或/status 等

在 Kubernetes 系统中，所有的对象型资源都有一个独有的名称表示以实现其冥等的创建及获取操作。有的
资源隶属于集群范畴，如 Namespace 和 PersistentVolume，而多数资源类型则受限于名称空间，如 Pod、
Deployment 和 Service 等。名称空间级别的资源的 URL 路径中含有其所属空间的名称，这些资源对象在
名称空间被删除时会被一并删除，这些资源的访问也受控于其所属的名称空间级别的授权。

Kubernetes 将 API 分割为多个逻辑组合，称为API 群组，不同的群组支持单独启用或禁用，并可以再次
分解。群组化管理的 API 使得其可以更轻松的进行扩展。当前 K8s 集群系统上的 API server 上的相关信息可以
使用kubectl api-versions获取。配置资源清单时会使用 API 群组：

# API群组
root@kube-master1:~# kubectl api-versions
admissionregistration.k8s.io/v1
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1
authentication.k8s.io/v1
authentication.k8s.io/v1beta1
authorization.k8s.io/v1
authorization.k8s.io/v1beta1
autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2
batch/v1
batch/v1beta1
certificates.k8s.io/v1beta1
coordination.k8s.io/v1
coordination.k8s.io/v1beta1
discovery.k8s.io/v1beta1
events.k8s.io/v1beta1
extensions/v1beta1
networking.k8s.io/v1
networking.k8s.io/v1beta1
node.k8s.io/v1beta1
policy/v1beta1
rbac.authorization.k8s.io/v1
rbac.authorization.k8s.io/v1beta1
scheduling.k8s.io/v1
scheduling.k8s.io/v1beta1
storage.k8s.io/v1
storage.k8s.io/v1beta1
v1

Kubernetes 的 API 以层级结构组织在一起，常用的 API 群组可以归为以下两类：

• 核心群组(core group)： REST 路径为/api/v1，在资源的配置信息apiVersion字段中
  引用时可以不用指定路径，如:“apiVersion: v1”

• 命名的群组(named group)： REST 路径为/api/$GROUP_NAME/$VERSION，例如
  /apis/apps/v1，其在 apiVersion 字段中引用的格式为:“apiVersion:$GROUP_NAME/$VERSION”，
  如：“apiVersion: apps/v1”

• 获取名为 apps 的 API 群组信息：

root@kube-master1:~# kubectl get --raw /apis/apps | jq
{
   
  "kind": "APIGroup",
  "apiVersion": "v1",
  "name": "apps",
  "versions": [
    {
   
      "groupVersion": "apps/v1",
      "version": "v1"
    }
  ],
  "preferredVersion": {
   
    "groupVersion": "apps/v1",
    "version": "v1"
  }
}

• 获取所有的 Deployment 对象的列表：

root@kube-master1:~# kubectl get --raw /apis/apps/v1/deployments | jq .
{
   
  "kind": "DeploymentList",  # Deployment列表
  "apiVersion": "apps/v1",
  "metadata": {
   
    "selfLink": "/apis/apps/v1/deployments",
    "resourceVersion": "369960"
  },
  "items": [
      ...
  ]

1.3 访问 Kubernetes REST API

可以使用 curl 作为 http 客户端直接通过 API server 在集群上操作资源对象模拟请求和响应
过程，只不过 kubeadm 部署的 k8s 集群默认只支持 HTTPS 协议访问接口，但是用户可以使用
kubectl proxy命令来在本地主机上为 API server 启动一个代理网关，由其支持使用 HTTP 进行
通信。

• 启动一个代理

root@kube-master1:/opt/k8s-data/yaml/proj1# kubectl proxy --port=8081
Starting to serve on 127.0.0.1:8081

• 访问

root@kube-master1:~# curl 127.0.0.1:8081/api/
{
   
  "kind": "APIVersions",
  "versions"