k8s-集群资源介绍及管理

k8s集群资源介绍及管理

1.k8s中的资源

K8s 中所有的内容都抽象为资源， 资源实例化之后，叫做对象

在k8s中,任何可以被申请、分配，最终被使用的对象，都是 kubernetes 中的资源，比如 CPU、内存。

1.1集群资源分类

1.1.1名称空间级别资源

仅在此名称空间下生效，如k8s的系统组件是默认放在kube-system名称空间下的，而kubectl get pod等价于kubectl get pod -n default，因此查看不到k8s的系统组件。

1.工作负载型资源(workload）：Pod【k8s最小组成部分，共享网络栈共享存储卷】、ReplicaSet【RS，调度器、控制器，通过标签去控制pod的创建、副本数量】、Deployment【控制器，通过控制RS的创建去创建pod】、StatefulSet【为有状态服务所建立的管理器】、DaemonSet【可以在每一个节点都运行一个pod的组件】、Job【工作、任务】、CronJob【轮询工作、轮询任务，为批处理而生的】（ReplicationController在v1.11版本被废弃）

2.服务发现及负载均衡型资源（ServiceDiscovery LoadBalance):Service【简称svc，服务，将服务暴露出去】、Ingress【将服务暴露出去】、…

3.配置与存储型资源：Volume（存储卷）【给pod提供持久化的能力】、CSI（容器存储接口，可以扩展各种各样的第三方存储卷)

4.特殊类型的存储卷：ConfigMap（当配置中心来使用的资源类型）【一般用来存储配置文件达到热更新的状态】、Secret（保存敏感数据）【加密方案存储数据，一般用来保存密码文件、密钥等等】、DownwardAPI（把外部环境中的信息输出给容器）【类似于CSI，】

利用KUBERNETES名称空间来管理内存和CPU资源

1.1.2集群级别资源

全集群可见可调用,不属于任何名称空间，因此资源对象的名称必须全局唯一。

不管在任何名称空间下定义，在其他的名称空间下都能看得到，在定义的时候无需指定名称空间.例如：Namespace【名称空间】、Node【节点】、Role【角色】、ClusterRole、RoleBinding、ClusterRoleBinding

1.1.3元数据型

可以通过指标进行操作。

提供一个指标，不像是名称空间类型又不像集群级别，本质上更像是在两者之间，但是它有自己的特点，所以更应该作为一个单独的分类，例如HPA【通过cpu的利用率进行平滑扩展】就是一个很明显的元数据类型，通过指标进行操作。根据一些指标去进行对应的操作.例如：HPA、PodTemplate【pod模板】、LimitRange【资源限制】.

如HPA,可以通过CPU当前利用率进行平滑扩展

1.2资源介绍

1.2.1 Pod

Pod是Kubernetes调度的最小单元。一个Pod可以包含一个或多个容器，因此它可以被看作是内部容器的逻辑宿主机。Pod的设计理念是为了支持多个容器在一个Pod中共享网络和文件系统 因此处于一个Pod中的多个容器共享以下资源：

PID命名空间：Pod中不同的应用程序可以看到其他应用程序的进程ID。

network命名空间：Pod中多个容器处于同一个网络命名空间，因此能够访问的IP和端口范围都是相同的。也可以通过localhost相互访问。

IPC命名空间：Pod中的多个容器共享Inner-process Communication命名空间，因此可以通过SystemV IPC或POSIX进行进程间通信。
UTS命名空间：Pod中的多个容器共享同一个主机名。

Volumes：Pod中各个容器可以共享在Pod中定义分存储卷（Volume）。

Pod好处:

Pod做为一个可以独立运行的服务单元，简化了应用部署的难度，以更高的抽象层次为应用部署管提供了极大的方便。

Pod做为最小的应用实例可以独立运行，因此可以方便的进行部署、水平扩展和收缩、方便进行调度管理与资源的分配。

Pod中的容器共享相同的数据和网络地址空间，Pod之间也进行了统一的资源管理与分配。

Pod，容器与Node（工作主机）之间的关系如下图所

K8S集群内POD/容器创建的过程：

apiVersion: v1
kind: Pod
metadata:
  name: nginx1
  labels:
    app: web
spec:
  containers:
    \- name: front-end
      image: nginx
      ports:
        \- containerPort: 80

1.2.2Label（标签）

在为对象定义好Label后，其他对象就可以通过Label来对对象进行引用。Label的最常见的用法便是通过spec.selector来引用对象。

apiVersion: v1
kind: ReplicationController
metadata:
name: nginx
spec:
replicas: 3
selector:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80

关于Label的用法重点在于这两步：

通过template.metadata.labels字段为即将新建的Pod附加Label。在上面的例子中，新建了一个名称为nginx的Pod，它拥有一个键值对为app:nginx的Label。

通过spec.selector字段来指定这个RC管理哪些Pod。在上面的例子中，新建的RC会管理所有拥有app:nginxLabel的Pod。这样的spec.selector在Kubernetes中被称作Label Selector。

使用Label可以给对象创建一组或多组标签，Service，ReplicationController ReplicaSet,Deployment等组件则通过Label Selector来定位需要管理的对象，Label和Label Selector共同构成了Kubernetes系统中最核心的应用模型，使得对象能够精细分组，同时实现了集群的高可用性。

1.2.3 Deployment

Deployment一般使用的场景都是和RS一起使用，那它们的具体原理是怎样的呢？
先看一下Deployment、RS、Pod它们三者之间的关系：

RS负责控制副本数量，由Deployment来创建具体的Pod，但是如果遇到版本更新的操作会怎样呢？

Deployment控制器支持两种更新策略：滚动更新（rolling update）和重新创建（recreate），默认为滚动更新。

Kubernetes之Deployment详解

1.2.4 Replication Controller

在旧版本的Kubernetes中，只有ReplicationController对象。它的主要作用是确保Pod以你指定的副本数运行，即如果有容器异常退出，会自动创建新的 Pod 来替代；而异常多出来的容器也会自动回收。可以说，通过ReplicationController，Kubernetes实现了集群的高可用性。

Replication Controller已经过期,建议使用使用 Deployment 配合ReplicaSet.

RC只支持基于等式的Selector，而RS两种Selector都支持。而RC是很早版本就建议弃用的特征,因此实际项目中强烈建议使用Deployment来代替Repliation Controller (RC)

1.2.5 Replica Set

在新版本的 Kubernetes 中建议使用 ReplicaSet（简称为RS ）来取代 ReplicationController。ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字不一样，并且 ReplicaSet 支持集合式的 selector（ReplicationController 仅支持等式）。

由于Replication Controller与Kubernetes代码中的模块Replication Controller同名，同时这个词也无法准确表达它的意思，所以从Kubernetes v1.2开始，它就升级成了另外一个新的对象——Replica Set，官方解释为“下一代的RC”。它与RC当前存在的唯一区别是：Replica Set支持基于集合的Label selector（Set-based s