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，完成了。