Kubernetes笔记(3) - 资源管理基础

Kubernetes系统将一切事物都抽象为API资源，其遵循REST架构风格组织并管理这些资源及其对象，同时还支持经过标准的HTTP方法（POST、PUT、PATCH、DELETE和GET）对资源进行增、删、改、查等管理操做。
Kubernetes的资源对象大致可分为

• 工做负载（Workload）
• 服务发现和负载均衡（Discovery & LB）
• 配置和存储（Config & Storage）
• 集群（Cluster）
• 元数据（Metadata）

资源对象及API群组

工做负载

Pod是工做负载型资源中的基础资源，它负责运行容器，并为其解决环境性的依赖。它被Pod控制器管理，但因为应用程序有无状态和有状态的区分，它们对环境的依赖及工做特性有很大的不一样，所以分属两种不一样类型的Pod控制器来管理。
管理无状态应用的控制器：

• ReplicationController
• ReplicaSet
• Deployment

ReplicationController和ReplicaSet的做用都是确保每一个Pod副本在任一时刻都符合目标数量。但ReplicationController是上一代的控制器，已基本废弃。
Deployment用于管理无状态的持久化应用，例如HTTP服务器；它用于为Pod和ReplicaSet提供声明式更新，是建构在ReplicaSet之上的更为高级的控制器。

管理有状态应用的控制器：

• StatefulSet

StatefulSet用于管理有状态的持久化应用，如database服务程序；其与Deployment的不一样之处在于StatefulSet会为每一个Pod建立一个独有的持久性标识符，并会确保各Pod之间的顺序性。

另外还有两个比较特别的Workload控制器：

• DaemonSet
• Job控制器

DaemonSet经常使用于运行集群存储守护进程——如glusterd和ceph，还有日志收集进程——如fluentd和logstash，以及监控进程——如Prometheus的Node Exporter、collectd、Datadog agent和Ganglia的gmond等。‰

Job控制器用于管理运行完成后便可终止的应用，例如批处理做业任务。

服务发现和负载均衡

Kubernetes使用标准的资源对象来负责服务发现和负载均衡，包括：

• Service资源
• Endpoint资源
• Ingress资源

配置与存储

Docker使用Volume来进行数据的持久化，K8S也为此提供了
Volume资源，并且它基于标准的CSI（Container Storage Interface）接口，支持多种类型的存储系统。

另外，Docker在启动容器时须要注入环境变量，K8S也为此提供了ConfigMap资源，它能够环境变量或存储卷的方式接入到Pod资源的容器中，而且可被多个同类的Pod共享引用。Secret资源则用于提供密码等敏感配置信息。

集群级资源

上述资源都属于名称空间级别，可由相应的项目管理员所管理。Kubernetes还存在一些集群级别的资源，用于定义集群自身配置信息，它们仅应该由集群管理员进行操做。

• Namespace: 资源对象名称的做用范围，绝大多数对象都隶属于某个名称空间，默认属于default.
• Node: Kubernetes集群的工做节点，其标识符在当前集群中必须是惟一的.
• Role: 名称空间级别的由规则组成的权限集合，可被RoleBinding引用.
• ClusterRole: Cluster级别的由规则组成的权限集合，可被RoleBinding和ClusterRoleBinding引用.
• RoleBinding: 将Role中的许可权限绑定在一个或一组用户之上，它隶属于且仅能做用于一个名称空间.
• ClusterRoleBinding: 将ClusterRole中定义的许可权限绑定在一个或一组用户之上;它可以引用全局名称空间中的ClusterRole，并能经过Subject添加相关信息.

元数据型资源

元数据型资源用于为集群内部的其余资源配置其行为或特性，如HorizontalPodAutoscaler资源可用于自动伸缩工做负载类型的资源对象的规模，Pod模板资源可用于为pod资源的建立预制模板，而LimitRange则可为名称空间的资源设置其CPU和内存等系统级资源的数量限制等。

资源在API中的组织形式

除了kubectl，也可使用curl、postman等工具做为HTTP客户端直接经过API Server在集群上操做资源对象，可是Kubernetes集群默认仅支持HTTPS的访问接口，它需进行一系列的认证检查，因此首先须要在本地主机上为API Server启动一个代理网关

kubectl proxy --port=8080

而后就能够发起请求了，好比获取集群的namespace list：

curl localhost:8080/api/v1/namespaces

与执行这样的命令获得的结果相同：

kubectl get namespaces -o json

全部的response都包含相同的一级字段：kind、apiVersion、metadata、spec、status。
其中kind、apiVersion分别表示对象所属的资源类型和API的版本。

metadata字段

metadata字段用于描述对象的属性信息，其内嵌多个字段用于定义资源的元数据，例如name和labels等。这些字段分为必要字段和可选字段两大类。好比名称空间级别的资源的必选字段包括有

• namespace：指定当前对象隶属的名称空间，默认值为default。‰
• name：设定当前对象的名称，在其所属的名称空间的同一类型中必须惟一。‰
• uid：当前对象的惟一标识符，其惟一性仅发生在特定的时间段和名称空间中

可选字段一般是指由Kubernetes系统自行维护和设置，或者存在默认值，或者自己容许留空。用户经过配置清单建立资源时，一般仅须要给出必选字段，可选字段可按需指定，对于用户未明肯定义的嵌套字段，则须要由一系列的finalizer组件自动予以填充。

spec和status字段

spec来描述所指望的对象应该具备的状态，status字段则用来记录对象的当前状态。在定义资源配置清单时，spec是必须定义的字段，status字段则由Kubernetes负责填充或更新，用户不能手动进行定义。

上述字段的子节点的内容随资源的种类不一样而有较大的区别，可使用kubectl explain来具体查看，好比

kubectl explain pods
kubectl explain pods.spec

资源对象管理

总体来讲，K8S提供了两类资源管理的方式：陈述式和声明式
陈述式侧重于告诉计算机如何执行操做，run、expose、delete和get等命令都属于此类；
声明式侧重于构建程序逻辑而无须详细描述其实现流程，用户只须要设按期望的状态，系统即能自行肯定须要执行的操做以确保达到用户指望的状态，全部的操做都经过apply命令来完成。

kubectl命令可以读取.yaml .yml或.json为格式的文件。-f选项能够指定配置清单的路径、URL或目录，且可重复使用屡次。若是指定的目录路径存在子目录中时，可以使用-R选项来递归获取子目录中的配置清单。

能够为每一个资源使用专用的配置清单，也能够将多个相关的资源（例如，属于同一个应用或微服务）组织在同一个配置清单中。不过，若是是YAML格式的配置清单，多个资源彼此之间要使用“---”符号做为单独的一行进行资源分割

管理namespace资源

namespace资源属于集群级别的资源，用于将集群分隔为多个隔离的逻辑分区以配置给不一样的用户、租户、环境或项目使用，namespace下又包含了pod、service等资源。
Kubernetes的namespace资源与Linux系统的名称空间是各自独立的概念。前者仅用于限制资源对象名称的做用域。
kubectl get namespaces命令可查看全部的namespaces资源，kube-system主要用于运行系统级资源，而default下则包含那些未指定名称空间的资源。
kubectl describe namespaces <namespace>命令可查看指定namespace的详细信息。
查看namespace级别的资源须要指定namespace名称，好比

kubect get pods -n kube-system

声明式建立namespace资源

使用apply命令基于如下配置清单建立namespace资源

3_namespace-example.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: dev
spec:
  finalizers:
  - kubernetes

~ kubectl apply -f 3_namespace-example.yaml 
namespace/dev created

建立namespace资源所需的属性较少，简单起见，kubectl为其提供了一个封装的专用陈述式命令kubectl create namespace <namespace>

删除Namespace资源

删除Namespace资源会级联删除其包含的全部其余资源对象

kubectl delete namespace dev

也能够为其指定--force --grace-period 选项

管理pod资源

首先定义以下资源清单：
3_pod-example.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-example
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1

建立Pod资源
陈述式对象配置方式：

kubectl create -f 3_pod-example.yaml

声明式对象配置方式：

kubectl apply -f 3_pod-example.yaml

查看pod状态

kubectl get -f 3_pod-example.yaml
或
kubectl get pod pod-example

同时可使用-o yaml/json选项获取详细的资源清单。
describe命令可查看活动对象的详细信息。

kubectl describe -f 3_pod-example.yaml 
或
kubectl describe pod pod-example

更新Pod资源
对于活动对象，并不是其每一个属性值都支持修改，好比没法修改Pod资源对象的metadata.name字段，除非删除并重建它。对于那些支持修改的属性，好比，容器的image字段，可将其完整的配置清单导出于配置文件中并更新相应的配置数据，然后使用replace命令基于陈述式对象配置的管理机制进行资源对象的更新。

~ kubectl get pods pod-example -o yaml > pod-example-update.yaml
将image修改成ikubernetes/myapp:v2后执行：
~ kubectl replace -f pod-example-update.yaml
操做成功会提示：
pod/pod-example replaced

上述使用了陈述式对象配置方式更新活动对象的配置，replace命令要重构整个资源对象，因此它必须基于完整格式的配置信息才能进行活动对象的彻底替换。若要基于此前的配置文件进行替换，就必须使用--force选项删除此前的活动对象，然后再进行新建操做。

~ kubectl replace -f 3_pod-example.yaml --force
pod "pod-example" deleted
pod/pod-example replaced

后面介绍会介绍更推荐的声明式管理方式。
删除Pod资源
陈述式命令方式：

kubectl delete pod pod-example

陈述式对象配置管理方式：

kubectl delete -f 3_pod-example.yaml

陈述式对象配置 VS 声明式

陈述式命令、陈述式对象配置、声明式三种管理K8S资源的方式中，后两种都是使用配置清单，但它们区别较大：
陈述式对象配置管理机制中，同时指定的多个资源必须进行同一种操做，并且其replace命令是经过彻底替换现有的活动对象来进行资源的更新操做，对于生产环境来讲，这并不是理想的选择。
声明式对象配置操做在管理资源对象时将配置信息保存于目标对象的注解中，并经过比较活动对象的当前配置、前一次管理操做时保存于注解中的配置，以及当前命令提供的配置生成更新补丁从而完成活动对象的补丁式更新操做。
好比要更新pod镜像，只须要修改最初的3_pod-example.yaml，而后apply，系统就会进行补丁式更新操做。
而资源对象的删除操做依然可使用apply命令，但要同时使用--prune选项，命令的格式为“kubectl apply -f --prune -l ”。但这个命令要慎用，由于它将基于标签选择器过滤出全部符合条件的对象，并检查由-f指定的目录中是否存在某配置文件已经定义了相应的资源对象，那些不存在相应定义的资源对象将被删除。所以，删除资源对象的操做依然建议使用陈述式对象配置方式。

学习资料

《Kubernetes实战进阶》 马永亮著