kubernetes(二)——基本资源

目录

1、整体架构

2、基本对象

---

1、整体架构

Kubernetes由Master节点和Node节点组成。master节点控制 Kubernetes 节点的机器，也是创建作业任务的地方，而node节点则在master的控制下执行被分配的任务。

Master主要由ETCD/Controller Manager/Api Server/Schedular能成,

• etcd：主要负责存储各个node节点的状态和其它相关数据，可以理解为kubernetes的数据库。
• API server：集群的统一入口，各组件协调者，以RESTful API提供接口服务，所有对象资源的增删改查和监听操作都交给API Server处理后再提交给 etcd 存储。
• Scheduler：实现集群节点的调度。根据调度算法为新创建的 Pod 选择一个Node 节点，可以任意部署，可以部署在同一个节点上，也可以部署在不同的节点上。调度算法考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。
• Controller Manager：处理集群中常规后台任务，一个资源对应一个控制器，而ControllerManager就是负责管理这些控制器的。

Node主要由kubelet和kube-proxy组成，一般还会安装kube-dns组件。

• Kubelet：是Master在Node节点上的代理，管理本机运行容器的生命周期，比如创建容器、Pod挂载数据卷、下载secret、获取容器和节点状态等工作。kubelet将每个Pod转换成一组容器。 kubelet 不会管理不是由 Kubernetes 创建的容器。
• Kube-proxy：在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
• Kube-dns:负责为整个集群提供DNS服务，通过Service名称访问相应的服务

各组件启动顺序：k8s的启动过程的先启动master上的kubelet，master上的kubelet启动etcd，kube-apiserver、kube-controller、  kube-scheduler, 这些系统服务pods( 静态 Pod（Static Pod）由特定节点上的 kubelet 守护进程直接管理的 pod)，这样k8s的master就启动成功了。

nodes上的kubelet会根据记录的master地址（直接ip地址，不需要网络转发），和kube-apiserver联系，kube-apiserver会让每台机器上的kube-proxy、coredns等系统组件，最后启动etcd里面记录的跟踪组件（pod容器方式），最后k8s整个集群启动成功
 

2、基本对象

Pod：Pod是Kubernetes创建或部署的最小单位。一个Pod封装一个或多个容器（container）、存储资源（volume）、一个独立的网络IP以及管理控制容器运行方式的策略选项。

Deployment：Deployment是对Pod的服务化封装。一个Deployment可以包含一个或多个Pod，每个Pod的角色相同，所以系统会自动为Deployment的多个Pod分发请求。

StatefulSet：StatefulSet是用来管理有状态应用的对象。和Deployment相同的是，StatefulSet管理了基于相同容器定义的一组Pod。但和Deployment不同的是，StatefulSet为它们的每个Pod维护了一个固定的ID。这些Pod是基于相同的声明来创建的，但是不能相互替换，无论怎么调度，每个Pod都有一个永久不变的ID。

Job：Job是用来控制批处理型任务的对象。批处理业务与长期伺服业务（Deployment）的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出（Pod自动删除）。

CronJob：CronJob是基于时间控制的Job，类似于Linux系统的crontab，在指定的时间周期运行指定的任务。

DaemonSet：DaemonSet是这样一种对象（守护进程），它在集群的每个节点上运行一个Pod，且保证只有一个Pod，这非常适合一些系统层面的应用，例如日志收集、资源监控等，这类应用需要每个节点都运行，且不需要太多实例，一个比较好的例子就是Kubernetes的kube-proxy。

Service：Service是用来解决Pod访问问题的。Service有一个固定IP地址，Service将访问流量转发给Pod，而且Service可以给这些Pod做负载均衡。

Ingress：Service是基于四层TCP和UDP协议转发的，Ingress可以基于七层的HTTP和HTTPS协议转发，可以通过域名和路径做到更细粒度的划分。

ConfigMap：ConfigMap是一种用于存储应用所需配置信息的资源类型，用于保存配置数据的键值对。通过ConfigMap可以方便的做到配置解耦，使得不同环境有不同的配置。

Secret：Secret是一种加密存储的资源对象，您可以将认证信息、证书、私钥等保存在Secret中，而不需要把这些敏感数据暴露到镜像或者Pod定义中，从而更加安全和灵活。

PersistentVolume（PV）：PV指持久化数据存储卷，主要定义的是一个持久化存储在宿主机上的目录，比如一个NFS的挂载目录。

PersistentVolumeClaim（PVC）：Kubernetes提供PVC专门用于持久化存储的申请，PVC可以让您无需关心底层存储资源如何创建、释放等动作，而只需要申明您需要何种类型的存储资源、多大的存储空间。

Namespace：资源的组织和划分。使用多Namespace可以将包含很多组件的系统分成不同的组。Namespace也可以用来做多租户划分，这样多个团队可以共用一个集群，使用的资源用Namespace划分开。

Label：Label 是识别 Kubernetes 对象的标签，以 key/value 的方式附加到对象上（key 最长不能超过 63 字节，value 可以为空，也可以是不超过 253 字节的字符串）。Label 不提供唯一性，并且实际上经常是很多对象（如 Pods）都使用相同的 label 来标志具体的应用。 Label 定义好后其他对象可以使用 Label Selector 来选择一组相同 label 的对象（比如ReplicaSet 和 Service 用 label 来选择一组 Pod）。

Annotations ： Annotations 是 key/value 形式附加于对象的注解。不同于 Labels 用于标志和选择对象， Annotations 则是用来记录一些附加信息，用来辅助应用部署、安全策略以及调度策略等。比如 deployment 使用 annotations 来记录 rolling update 的状态。

ReplicaSet： ReplicaSet （也简称为 rs ）用来确保容器应用的副本数始终保持在用户定义的副本

数，即如果有容器异常退出，会自动创建新的 Pod 来替代；而异常多出来的容器也会自动回收。

ReplicaSet 的典型应用场景包括确保健康 Pod 的数量、弹性伸缩、滚动升级以及应

用多版本发布跟踪等。