Kubernetes架构组件资源对象

所涉及内容：

Kubernetes概述；Kubernetes容器编排工具的优势；

容器部署和传统部署对比分析；Kubernetes中的资源对象。

Kubernetes是什么？

1、Kubernetes是一个可移植的、可扩展的、开源的容器管理平台，简称Kubernetes：

那么什么是可移植呢？

在Kubernetes中部署的应用都是基于镜像的，镜像是可移植的，可以被多个环境使用，可以从一个环境迁移到另一个环境。

什么是可扩展呢？

安装Kubernetes的物理节点可以根据业务规模动态扩缩容，Kubernetes中的Pod应用也可以实现自动扩缩容。

什么是开源的呢？

源代码已经公开，有许多的技术人员在开发维护，可以被用户免费使用。

2、（重点理论来了）：Kubernetes提供了应用程序的快速部署、升级和回滚的能力，利用service可以实现服务注册、发现；通过kube-proxy可以实现负载均衡，通过cordns可实现域名解析，通过Ingress可以实现七层负载均衡等功能。

3、可以对容器自动化部署、自动化扩缩容、跨主机管理等。

4、可以对代码进行灰度发布、金丝雀发布、蓝绿发布、滚动更新等。

5、具有完整的监控系统和日志收集平台，具有故障自动恢复的能力。

Kubernetes架构：单节点和高可用架构

Kubernetes的物理架构是master/node模式：

Kubernetes集群至少需要一个主节点Master和多个工作节点Worker，主节点是集群的控制节点，负责整个集群的管理和控制，主节点主要用于暴露API、调度部署和节点的管理。工作节点主要是运行容器的。

Kubernetes组件：

kubectl：管理 Kubernetes的命令行工具，可以操作 Kubernetes中的资源对象。

etcd：是一个高可用的键值数据库，存储 Kubernetes的资源状态信息和网络信息的，etcd 中的数据变更是通过 api server 进行的。

apiserver: 提供 Kubernetesapi，是整个系统的对外接口，提供资源操作的唯一入口，供客户端和其它组件调用，提供了 Kubernetes各类资源对象（pod,deployment,Service 等）的增删改查，是整个系统的数据总线和数据中心，并提供认证、授权、访问控制、API 注册和发现等机制，并将操作对象持久化到 etcd中。

scheduler：负责 Kubernetes集群中 pod 的调度的 ， scheduler 通过与 apiserver 交互监听到创建 Pod副本的信息后，它会检索所有符合该 Pod 要求的工作节点列表，开始执行 Pod 调度逻辑。调度成功后将Pod 绑定到目标节点上。

controller-manager：与 apiserver 交互，实时监控和维护 Kubernetes集群的控制器的健康情况，对有故障的进行处理和恢复。

kubelet： 每个 Node 节点上的 kubelet 定期就会调用 API Server 的 REST 接口报告自身状态，API Server 接收这些信息后，将节点状态信息更新到 etcd 中。kubelet 也通过 API Server 监听 Pod信息，从而对 Node 机器上的 POD 进行管理：如创建、删除、更新 Pod。

kube-proxy：提供网络代理和负载均衡，是实现 service 的通信与负载均衡机制的重要组件，kube-proxy 负责为 Pod 创建代理服务，从 apiserver 获取所有 service 信息，并根据 service 信息创建代理服务，实现 service 到 Pod 的请求路由和转发，从而实现 Kubernetes层级的虚拟转发网络，将到service 的请求转发到后端的 pod 上。

Calico：Calico 是一个纯三层的网络插件，calico 的 bgp 模式类似于 flannel 的 host-gw，calico在 kubernetes 中可提供网络功能和网络策略。

Cordns：Kubernetes1.11 之前使用的是 kube dns，1.11 之后才有 coredns，coredns 是一个 DNS 服务器，能够为 Kubernetes services 提供 DNS 记录。

Docker：是一个容器引擎，用于运行容器。

附加组件：

Web UI（Dashboard）：Dashboard 是 Kubernetes集群的一个 web ui 界面，通过这个界面可以对 Kubernetes资源进行操作，如创建 pod，创建存储，创建网络等，也可以监控 pod 和节点资源使用情况。

prometheus+alertmanager+Grafana：监控系统，可以对 kubernetes 集群本身的组件监控，

也可对物理节点，容器做监控，对监控到的超过报警阀值的数据进行报警

efk（全称 elasticsearch、fluentd、kibana）：日志管理系统，可以对物理节点和容器的日志进行统一收集，把收集到的数据在 kibana 界面展示，kibana 提供按指定条件搜索和过滤日志。

Metrics：用于收集资源指标，hpa 需要基于 metrics 实现自动扩缩容。

Kubernetes容器编排工具的优势

1、灵活部署

kubernetes 支持在多种平台部署，可在私有云，公有云，混合云，openstack、openshift、

VMware vSphere，VMware Workstation，虚拟机，物理机等环境部署。

2、安全高效，拥有完善的认证授权机制，自带审计功能可以对多用户做细化的授权管理（如 rbac 授权），达到相互之间的操作完全隔离，互不影响，而且自身带有审计功能，可以对操作过程进行实时的日志记录，出现问题可以方便排查。

3、负载均衡

支持四层、七层负载均衡，可用于多种场景。

4、可扩展性强

拥有强大的集群扩展能力，可以根据业务规模自动增加和缩减主机节点的数量，确保服务可以承受大量并发带来的压力，保证业务稳定运行。

5、根据节点资源的使用情况对 pod 进行合理的调度可以按照用户需要调度 pod，例如保证 Pod 只在资源足够的节点上运行，会尝试把同一功能的 pod分散在不同的节点上，还会尝试平衡不同节点的资源使用率等。

6、拥有完善的灾备预警方案拥有多种灾备解决方案，支持备份和容灾，出现故障可以达到秒级切换，保证线上业务不受影响。

容器部署和传统部署对比分析

1.传统部署时代：

早期，应用程序在物理服务器上运行。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，结果可能导致其他应用程序的性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展，并且许多物理服务器的维护成本也很高。

2.虚拟化部署时代：

作为解决方案，引入了虚拟化功能，它允许你在单个物理服务器的 CPU 上运行多个虚拟机（VM）。虚拟化功能允许应用程序在 VM 之间隔离，并提供安全级别，因为一个应用程序的信息不能被另一应用程序自由地访问。因为虚拟化可以轻松地添加或更新应用程序、降低硬件成本等，所以虚拟化可以更好地利用物理服务器中的资源，并可以实现更好的可伸缩性。每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。

3.容器部署时代：

容器类似 VM，但是它们具有轻量级的隔离属性，可以在应用程序之间共享操作系统（OS）。因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离，因此可以跨云和 OS 分发进行移植。容器因具有许多优势而变得流行起来。

Kubernetes中的资源对象

Pod 是 Kubernetes 中的最小调度单元，当指派容器时，容器实际上并不会指派到物理硬件上，容器会被分配到一个 Pod 里，一个 Pod 封装一个容器（也可以封装多个容器），Pod 里的容器共享存储、网络等。也就是说，应该把整个 pod 看作虚拟机，然后每个容器相当于运行在虚拟机的进程。所有容器都被统一安排和调度，并运行在共享的上下文中。

label 是标签的意思，Kubernetes中的资源对象大都可以打上标签，如 Node、Pod、Service 等，一个资源可以绑定任意多个 label，Kubernetes通过 Label 可实现多维度的资源分组管理，后续可通过 Label Selector 查询和筛选拥有某些 Label 的资源对象，例如创建一个 Pod，给定一个 Label 是app=tomcat，那么 service 可以通过 label selector 选择拥有 app=tomcat 的 pod，和其相关联，也可通过 app=tomcat 删除拥有该标签的 Pod 资源。

带有 Label 的对象创建好之后，我们就可以通过 Label Selector 来引用这些对象。我们通过资源清单文件中的 spec.selector 字段来指定 Label，从而 Kubernetes 寻找到所有包含你指定 Label 的对象，进行管理。

Deployment 管理 Replicaset 和 Pod 的副本控制器，Deployment 可以管理多个 Replicaset，是比 Replicaset 更高级的控制器，也即是说在创建 Deployment 的时候，会自动创建Replicaset，由 Replicaset 再创建 Pod，Deployment 能对 Pod 扩容、缩容、滚动更新和回滚、维持 Pod 数量。

控制器 Statefulset

Deployment 控制器是用来管理无状态应用的：管理的所有 Pod 一模一样，提供同一个服务，也不考虑在哪台 Node 运行，可随意扩容和缩容。这种应用称为“无状态”，例如 Web 服务，Deployment部署的 pod 数据卷是共享的，创建 3 个 pod 都是用的同一个数据卷，对外提供统一的服务。

在实际的场景中，尤其是分布式应用，会部署多个实例，这些实例之间往往有依赖关系，例如主从关系、主备关系，这种应用称为“有状态”，例如 MySQL 主从、Etcd 集群。

StatefulSet 控制器用于部署有状态应用，满足一些有状态场景的：

1、StatefulSet 管控的的每个 Pod 对象都有固定的主机名和专有存储卷，即便被重构后亦能保持不变

2、Pod 有序的部署、扩容、删除和停止

3、Pod 分配一个稳定的且唯一的网络标识

4、Pod 分配一个独享的存储

控制器 Daemonset

DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet将会删除它创建的所有 Pod。

使用 DaemonSet 的一些典型用法：

1、运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。

2、日志收集，比如 fluentd，logstash 等。

3、系统监控，比如 Prometheus Node Exporter，collectd，New Relic agent，Ganglia

gmond 等。

4、系统程序，比如 kube-proxy, kube-dns, glusterd, ceph 等。

控制器 Job&CronJob

Job 负责批量处理任务：Job 创建一个或多个 Pod，并确保指定数量的 Pod 成功终止。Pod 成功完成后，Job 将跟踪成功完成的情况。当达到指定的成功完成次数时，任务（即 Job）就完成了。删除Job 将清除其创建的 Pod；一个简单的情况是创建一个 Job 对象，以便可靠地运行一个 Pod 来完成。如果第一个 Pod 发生故障或被删除（例如，由于节点硬件故障或节点重启），则 Job 对象将启动一个新的 Pod。

Cron Job ：一个 CronJob 对象就像 crontab 文件中的一行。它用 Cron 格式进行编写，并周期性地在给定的调度时间执行 Job。在每次调度运行时间内大概会创建一个 Job 对象。我们之所以说大概是因为在特定的环境下可能会创建两个 Job，或者一个 Job 都没创建。

Ingress 可以把进入到集群内部的请求转发到集群中的一些服务上，从而可以把服务映射到集群外部。Ingress 能把集群内 Service 配置成外网能够访问的 URL，流量负载均衡，提供基于域名访问的虚拟主机等。

Ingress Controller 可以理解为控制器，它通过不断的跟 Kubernetes API 交互，实时获取后端Service、Pod 的变化，比如新增、删除等，结合 Ingress 定义的规则生成配置，然后动态更新上边的 Nginx 或者 trafik 负载均衡器，并刷新使配置生效，来达到服务自动发现的作用。

实战：

1、

如何通过 Kubernetes创建一个 Pod 资源？
#编写一个资源清单文件
cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: tomcat-pod
namespace: default
labels:
tomcat: tomcat-pod


spec:
containers:
- name: tomcat-pod-java
ports:
- containerPort: 8080
image: tomcat:8.5-jre8-alpine
imagePullPolicy: IfNotPresent
#更新资源清单文件
kubectl apply –f pod.yaml
#查看创建的资源
[root@master1 ~]# kubectl get pods | grep tomcat
tomcat-pod 1/1 Running 0 6s

2、

如何定义一个 label？
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: backend
spec:
containers:
- name: nginx
image: nginx
ports:


- containerPort: 80
上面的资源清单文件为名为 nginx 的 Pod 添加了一个 Label，是 app: backend

创建 service：
apiVersion: v1
kind: Service #为 default backend 创建一个 service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
targetPort: 80
selector:
app: backend
Label selector：

3、

如何创建一个 Deployment 资源？
cat deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
matchLabels:
run: my-nginx
replicas: 2
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
ports:
- containerPort: 80
- 
#更新资源清单文件
kubectl apply –f deployment.yaml

#查看创建的 Deployment 资源

[root@master1 ~]# kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
my-nginx 2/2 2 2 36d

#查看创建的 Replicaset 资源

[root@master1 ~]# kubectl get rs
NAME DESIRED CURRENT READY AGE
my-nginx-5b56ccd65f 2 2 2 36d

#查看创建的 Pod 资源

NAME READY STATUS RESTARTS AGE
my-nginx-5b56ccd65f-d67nn 1/1 Running 0 9m21s
my-nginx-5b56ccd65f-m5cq7 1/1 Running 0 9m21s

4、

如何创建一个 service 资源？

创建一个 pod

cat pod_test.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
matchLabels:
run: my-nginx
replicas: 2
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
ports:
- containerPort: 80

创建一个 service
cat service.yaml
apiVersion: v1
kind: Service
metadata:
name: my-nginx

labels:
run: my-nginx
spec:
ports:
- port: 80
protocol: TCP
selector:
run: my-nginx

这篇对Kubernetes就写完了，自己感觉写的不够好，但是重点是其中有一些理论非常重要，比如组件和资源对象都很重要。一定要仔仔细细看完。

代码段可以先看看，后面编写发布的实战过程操作之后保证可以懂！！