Kubernetes_从云原生到kubernetes

一、前言

二、kubernetes和云原生

Cloud Native 直接翻译为云原生，云原生官网：https://www.cncf.io/

CNCF，表示 Cloud Native Computing Foudation ，翻译为 云原生计算基金会，属于Linux基金会，初衷是围绕“云原生”服务云计算，维护和集成开源技术，支持编排容器化微服务架构应用。

时至今日，Kubernetes逐渐已经成为云原生失败的基础设置。

Docker是容器化技术，Kubernetes是一种容器编排技术，之前还有一个Docker Swarm也是一种容器编排技术，但是已经不被使用。

云原生这三字，云表示在云服务器上部署，原生的意义就是 部署在一个陌生的环境，像部署在自己熟悉的环境上，类似于 JVM 一次编译，到处运行。

要实现云原生这个一次编译，到处运行，涉及很多组件，从小到大，Docker是容器化部署，Kubernetes是容器编排工具(Docker Swarm也是)，对Docker进行编排，就是通过 yaml 文件来实现；Helm是包管理工具，对Kubernetes的 yaml 进行编排，Helm 中通过 if 块可以用 values.yaml 文件中变量 精确的决定 kubernetes yaml 文件中哪一行是否需要被运用。

kubernetes是云原生时代基础设施，如下图：

上图表示，将应用部署在Kubernetes集群上，这样 应用就可以在 公有云 私有云 混合云 上无缝迁移。应用包括用于数据存储的有状态的应用，使用StatefulSet部署，不用于数据存储的无状态的应用，使用Deployment部署。

Kubernetes四种部署方式：Deployment StatefulSet DaemonSet Job(CronJob)
ReplicaSet 存在的意义就是 replicas 这个属性 how many Pods
Deployment 存在的意义就是无状态
StatefulSet 存在的意义就是有状态
DaemonSet 存在的意义就是日志 监控
Job(CronJob) 存在的意义是一次性任务和定时任务

小结：云原生这三字，云表示在云服务器上部署，原生的意义就是部署在一个陌生的环境，像部署在自己熟悉的环境上，类似于 JVM 一次编译，到处运行。容器化部署实现了这个目标，Kubernetes是一种容器编排技术，所以说Kubernetes是云原生时代基础设施，这就是Docker、Kubernetes与云原生的关系。

三、从Docker Swarm到Kubernetes

kubernetes本质是一个容器编排技术，docker内置的 docker swarm 也是做容器编排的，都是管理和编排Docker Container容器，但是对于容器编排，k8s更加优秀，是现在的主流。

重点学习kubernetes，docker swarmy了解即可，知道有这个东西即可。

Github上：https://github.com/kubernetes/kubernetes

docker swarm 架构设计（了解即可）

四、kubernetes组件和架构简介

4.1 kubernetes组件

本节官方地址（K8S Docs Concepts）：https://kubernetes.io/docs/concepts/

4.1.1 Container

(1)先以container为起点，k8s既然是容器编排工具，那么一定会有container

4.1.2 Pod

那k8s如何操作这些container呢？从感性的角度来讲，得要有点逼格，k8s不想直接操作container，因为操作container的事情是docker来做的，k8s中要有自己的最小操作单位，称之为Pod说白了，Pod就是一个或多个Container的组合

官方解释 ：https://kubernetes.io/docs/concepts/workloads/pods/pod/

A Pod (as in a pod of whales or pea pod) is a group of one or more containers (such as Docker containers), with shared storage/network, and a specification for how to run the containers.

4.1.3 ReplicaSet

那Pod的维护谁来做呢？那就是ReplicaSet，通过selector来进行管理

官方解释 ：https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/

A ReplicaSet is defined with fields, including a selector that specifies how to identify Pods it can acquire, a number of replicas indicating how many Pods it should be maintaining, and a pod template specifying the data of new Pods it should create to meet the number of replicas criteria.

4.1.4 Deployment

Pod和ReplicaSet的状态如何维护和监测呢？Deployment

官网是如何描述的 ：https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

A Deployment controller provides declarative updates for Pods and ReplicaSets. You describe a desired state in a Deployment, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.

4.1.5 Label与Selector

不妨把相同或者有关联的Pod分门别类一下，那怎么分门别类呢？Label

官网是如何描述的 ：https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

Labels are key/value pairs that are attached to objects, such as pods.

label 可以在任何类型的资源上，然后用 selector 选择器来选择，比如pod、node，都可以打标签。

4.1.6 Service

具有相同label的service要是能够有个名称就好了，Service

看官网上怎么说 ：https://kubernetes.io/docs/concepts/services-networking/service/

An abstract way to expose an application running on a set of Pods as a network service.

With Kubernetes you don’t need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, and can load-balance across them.

4.1.7 Node

上述说了这么多，Pod运行在哪里呢？当然是机器咯，比如一台centos机器，我们把这个机器称作为Node.

看看官网怎么说 ：https://kubernetes.io/docs/concepts/architecture/nodes/

A node is a worker machine in Kubernetes, previously known as a minion. A node may be a VM or physical machine, depending on the cluster. Each node contains the services necessary to run pods and is managed by the master components.

4.1.8 多Node节点组成的集群

难道只有一个Node吗？显然不太合适，多台Node共同组成集群才行嘛
画个图表示一下咯，最好能把之前的Label，Service也一起画上去，整体感受一下

此时，我们把目光转移到由3个Node节点组成的Master-Node集群

4.2 kubernetes架构

这个集群要配合完成一些工作，总要有一些组件的支持吧？接下来我们来想想有哪些组件，然后画一个相对完整的架构图

01-总得要有一个操作集群的客户端，也就是和集群打交道
回答：kubectl，每个集群node上都可以使用kubectl，只要 /root/.kube/config 文件。

02-请求肯定是到达Master Node，然后再分配给Worker Node创建Pod之类的 关键是命令通过kubectl过来之后，是不是要认证授权一下？
回答：Master Node上的apiserver，/etc/kubernetes/manifests目录下有 kube-apiserver.yaml 文件

03-请求过来之后，Master Node中谁来接收？
回答：APIServer

04-API收到请求之后，接下来调用哪个Worker Node创建Pod，Container之类的，得要有调度策略

回答：Master节点的上的静态Pod Scheduler 来负责。
官方资料：https://kubernetes.io/docs/concepts/scheduling/kube-scheduler/

05-Scheduler通过不同的策略，真正要分发请求到不同的Worker Node上创建内容，具体谁负责？
回答： Controller Manager

06-Worker Node接收到创建请求之后，具体谁来负责？
回答：Kubelet服务，最终Kubelet会调用Docker Engine，创建对应的容器[这边也反应出一点，在Node上需要有Docker Engine，才能创建维护容器]

07-会不会涉及到域名解析的问题？
回答：主节点上的CoreDNS服务

08-是否需要有监控面板能够监测整个集群的状态？
回答：Dashboard

09-集群中这些数据如何保存？
回答：分布式存储 ETCD

10-至于像容器的持久化存储，网络等可以联系一下
回答：Docker中的内容

11- 不妨用一个图片总结整个流程
回答：

这个图片上告诉我们：
(1) 对于主节点来说，kubectl 连接主节点的所有操作，都必须通过 apiserver 的认证、授权、准入控制，才能正常进行；
(2) 四个静态Pod: apiserver controllerManager scheduler etcd 都是运行在主节点上，apiserver用于认证、打开外网、rbac授权、controllerManager用来管理各种controller，包括 replicaset deployment statefulset daemonset job/cronjob，scheduler决定某个Pod分配哪个Node上，etcd作为配置中心存放数据。
(3) dashboard 提供简单的可视化，完整的可视化还是需要 Prometheus+Grafana 监控
(4) 默认情况下主节点有污点Taint，不分配Pod运行
(5) 每个节点上都会有 kubelet 服务，可以使用 systemctl status kubelet 查看
每个节点上都会有 docker 服务 ，可以使用 systemctl status docker 查看，其作用是将镜像image运行起来变为容器Container
每个节点上都会有 kube-proxy 容器 ，可以使用 kubectl get pod -o wide -n kube-system 查看，其作用是将 kubectl 发送到 service 的请求路由到 具体的Pod 上；
每个节点上都会有 calico/fluend 容器 ，可以使用 kubectl get pod -o wide -n kube-system 查看，其作用Node之间网络通信；
集群一些节点上有 dns 容器，可以使用 kubectl get pod -o wide -n kube-system 查看，其作用使用将 serviceName.namespace 解析为 集群内ip，也可以解析 外网域名，通过配置 /etc/resolv.conf nameserver域名解析服务器列表 和 /etc/hosts 本地域名解析文件来实现。

再来一张横向架构图图，加深理解，如下：

五、尾声

从云原生到kubernetes，完成了。