Kubernetes第零篇：从云原生到kubernetes

Kubernetes第零篇：从云原生到kubernetes

文章目录

​​一、前言​​​​二、kubernetes和云原生​​​​三、从Docker Swarm到Kubernetes​​​​四、kubernetes组件和架构简介​​

​​4.1 kubernetes组件​​

​​4.1.1 Container​​​​4.1.2 Pod​​​​4.1.3 ReplicaSet​​​​4.1.4 Deployment​​​​4.1.5 Label与Selector​​​​4.1.6 Service​​​​4.1.7 Node​​​​4.1.8 多Node节点组成的集群​​

​​4.2 kubernetes架构​​

​​五、尾声​​

一、前言

二、kubernetes和云原生

Cloud Native 直接翻译为云原生，云原生官网：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上：swarm 架构设计（了解即可）

四、kubernetes组件和架构简介

4.1 kubernetes组件

本节官方地址（K8S Docs Concepts）：Container

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

4.1.2 Pod

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

官方解释 ：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来进行管理

官方解释 ：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

官网是如何描述的 ：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

官网是如何描述的 ：are key/value pairs that are attached to objects, such as pods.

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

4.1.6 Service

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

看官网上怎么说 ：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.

看看官网怎么说 ：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 来负责。 官方资料：Node上创建内容，具体谁负责？ 回答： Controller Manager

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

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

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

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

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

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

五、尾声

认识kubernetes，完成了。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。