kubernetes基础——一文读懂k8s
容器
容器与虚拟机对比图(左边为容器、右边为虚拟机)
容器是独立的、隔离的，不同容器间不能直接通信，容器与宿主机也是隔离开来的，容器不能直接感知到宿主机的存在，同时宿主机也无法直接窥探容器内部。
虽然容器与宿主机在环境上，逻辑上是隔离的，但容器与宿主机共享内核，容器直接依赖于宿主机Linux系统的内核，这与虚拟机不同，后者是在宿主机的操作系统上，虚拟化一套硬件环境，然后在此环境上运行需要的操作系统。容器技术常用来在宿主机上隔离出环境来部署应用（用容器化技术部署的应用称为 “容器化应用” ），而虚拟机常用来运行一个与宿主机不同的操作系统，从而运行特定的软件。
容器量级非常轻，无论是启动速度，资源占用情况，灵活性等均优于虚拟机。容器的特性给开发生产提供了非常大的便利：
- DevOps理念，开发者可以使用同一个镜像，在开发环境、测试环境和生产环境构建相同的容器，即相同的程序运行环境，这样可以大大减少前期的环境部署时间，可以有效避免由于各个环境不一致而造成的灾难。
- “容器”与“微服务”常是一起出现的一组名词，有了容器技术以后，可以更加方便的部署微服务，例如，可以把评论服务部署到一个容器里，把阅读的服务部署到另一个容器，这样在一个服务崩溃时不至于影响到其它服务，再者，容器启动速度快，可以在极短时间内恢复。
- 很多时候，一些环境、工具需要复用，这时候容器是个很好的选择，我们可以把环境和工具打包成镜像，需要的时候用来构建容器使用。在Docker的镜像仓库上，也有很多官方的或第三方的镜像，这些镜像都是别人已经打包好的工具或者环境，我们只需一条命令，就可以把镜像拉取下来并构建容器启动，免去了自己动手开发部署的麻烦。
集群
计算机是独立的，但我们可以通过一系列技术、软件，把分散的算力有效的集中起来，把多台独立的计算机当做一个整体来使用，而且这些计算机实现相同的业务，这就是集群。
分布式
分布式就是把一个系统拆分开来部署到不同机器，与集群相同的是，两者都需要多台服务器，不同点是分布式并不强调实现相同的业务。貌似网上大多数资料，对于集群和分布式的区分，都执着于两者是否实现相同的业务，即不同服务器运行同一份功能就是集群，运行不同功能就是分布式。个人看法是，集群强调的是“集”、“统一的概念”，是物理上的、环境上的概念，只要是多台计算机搞在一起就是集群；而分布式，更多的是描述应用系统的部署方式，把一个系统拆开部署到不同服务器，就是分布式。这里有一篇关于分布式和集群的文章——浅谈集群与分布式的区别
微服务
有必要提一下微服务，使用kubernetes可以更加便捷地部署微服务应用。微服务和分布式都强调“拆”、“分”，但微服务描述的是应用系统的架构，即怎么样把系统拆分，拆成多“微”，这是微服务需要考虑的；而分布式，强调的是“分布”，即系统的部署方式，该怎么把系统的模块分布好，从而提高容灾能力、高可用性。当“微服务”应用部署到一台服务器上，它就是“微服务应用”，当把“微服务”应用的模块分开来部署到不同服务器，那么它也成了“分布式应用”。
关于“集群”、“分布式”、“微服务”三者的联系与区别——微服务，分布式，集群三者区别联系
kubernetes
"kubernetes"这个词比较长，常简写成k8s，"8"表示中间的8个字母。k8s是谷歌开源的用于管理 “容器化应用” 和服务的平台，可用于自动部署、扩展和管理“容器化（containerized）应用程序”。可以通过一条命令或一份配置文件实现自动创建容器并部署应用，还提供应用容器的自动化管理功能（自动扩容、自动缩容）。k8s支持搭建集群，因此，k8s也是容器化集群管理平台，它旨在提供“跨主机集群的自动部署、扩展以及运行应用程序容器的平台”，它支持一系列容器工具, 包括Docker等。通过k8s以及容器引擎(Docker或rtk或其它)，可以非常方便快速地搭建集群环境。这样部署出来的集群有一个特点——容器化，在集群中部署的应用，都是采用容器化的方式进行部署，即把应用放到容器中运行，至于这个容器是在集群中哪个节点运行，就交由集群管理人员和k8s控制。
通过k8s，能够进行应用的自动化部署和扩缩容，k8s可以根据事先配置好的配置文件，实时监控容器的运行状态，当容器出现问题时，k8s会自动地重建容器，当负载上升时，k8s会自动扩容，创建新的容器。k8s会尽量地维持容器的数量，当容器出现问题不能运行时，它会被删除，同时k8s会新建容器，以满足配置文件指定的容器数量要求。这里说“容器”其实并不恰当，因为k8s的基本调度单位是“pod”，下文会介绍。
以上都是比较笼统的说法，可以用稍微专业一点的术语来描述，k8s根据其特点，可以归纳成如下的功能:
-
跨主机的自动化容器编排管理平台
k8s以“Pod”为基本单位跨主机管理容器，“Pod”是一组（或一个）容器的集合。k8s监控集群中各个节点（主机）上Pod的健康状态，能够利用用户配置的“控制器”，及时地剔除不健康的Pod，同时创建新的健康的Pod来替代原来的Pod，这整个过程都是自动化的，用户只需配置Pod的“控制器”，其余操作均由k8s系统完成。
Pod“控制器”一般包含“replicas”属性，在介绍该属性前，先引入“副本”的概念——一个Pod可以被复制成多份，每一份可被称之为一个“副本”，这些“副本”除了一些描述性的信息（Pod的名字、uid等）不一样以外，其它信息都是一样的，譬如Pod内部的容器、容器数量、容器里面运行的应用等的这些信息都是一样的，这些副本提供同样的功能。“replicas”属性则指定了特定Pod的副本的数量，当当前集群中该Pod的数量与该属性指定的值不一致时，k8s会采取一些策略去使得当前状态满足配置的要求。
Pod是要被分配到节点（主机）中去运行的，至于要被分配到那个节点去，可以由用户去配置，默认情况下，k8s系统会根据各个节点的资源状况（当前资源的分配情况、资源的最大配额等信息），采取合适的分配策略对Pod进行调度，对资源进行调度。这里的资源是指CPU资源、内存资源等等。 -
微服务部署平台
鉴于k8s有以上所描述的如此优良的特性，使用k8s来部署微服务应用是极佳的，k8s也提供了很多可以实行微服务部署的功能。
可以基于上述的k8s的Pod编排技术，实现微服务的服务编排、服务快速部署。
k8s提供了service的概念，service是对Pod访问方式的抽象，service就是“服务”，service与一组Pod挂钩，Pod实现某些功能，service就是利用Pod的“功能”，利用“Pod”的能动性，对外提供“服务”。service对请求进行路由，负载均衡到它后面与之挂钩的Pod。利用service，可以实现微服务的服务自动发现和路由。
k8s的一些Pod“控制器”可以提供Pod的“滚动更新”功能，如果你的应用升级了，譬如原来应用是v1版本，现在的版本是v2，那么可以通过仅仅一条命令或一份配置文件，让k8s来自动地滚动更新应用。k8s会删除一个v1的Pod，然后新建一个v2的Pod……这样反复交替操作，直至所有v1Pod被v2Pod代替，这样就实现了不停机的应用滚动更新。k8s会保存应用的更新记录，在需要“回滚降级”时，同样可以通过仅仅一条命令或者一个配置文件实现。
服务伸缩。当遇到类似“双十一”这样的时效性的业务需求时，可以充分利用到k8s了。如上面提到的“replicas”属性，该属性可以用来指定Pod的副本数量，当业务量增大时，可以修改该属性值，让k8s创建更多的Pod来处理请求，相应的，当业务量减少时，为了节约资源，可以减少该属性的值。这样就实现了服务的动态伸缩，用户只需修改配置，实际操作交由k8s负责。
更多资料:
k8s基础概念解析
Pod
更多资料:
Service
PodIP是在集群内部的IP，外网无法访问，相应的，Pod也是不能被外部访问的，Pod只能在集群内部被直接访问，那么如何在外网访问Pod里面部署的网站、应用？那就是上文提到的service。
service是对Pod访问方式的一种抽象。当请求发送给service，service再把请求路由到与之挂钩的Pod。在k8s中，service被用来给Pod暴露（expose）服务，service暴露的服务不仅仅是用来给外网访问，内网也是可以使用的。默认情况下，service被配置为ClusterIp模式，在该模式下，也是只有集群内部的网络才能访问到该service，要想真正的实现外网访问service，需要把service访问方式配置为NodePort或用其它方式（ingress、loadbalancer等）。
service降低了k8s中Pod的耦合度。使用服务的Pod（称为“前端”frontend）和提供服务的Pod（称为“后端”backend）不是耦合在一起的。backend随时会变动（Pod可能因为某些原因被销毁又重建），frontend并不关心它实际上调用哪个backend副本，他只关心service的状态，而backend的状态，则转交给了service去跟踪。
更多资料:
Node(节点)
一个node，就是k8s集群中的一个服务器，node分为Master Node和Worker Node。
Master Node
顾名思义，Master Node就是集群中的控制中心，负责整个集群的控制、管理。默认情况下，在部署集群时master会被分配一个名为NoSchedule的Taint(污点)，这个taint使得master节点不能被调度，也就是说新建Pod时，Pod不会被分配到master节点。
Worker Node
Worker Node用于承载应用的运行，k8s会根据配置文件中的策略，对worker node进行调度，把pod分配到合适的worker node。
CRI(容器运行时接口)
全称"Container-Runtime-Interface"，是一个接口，用来操作容器的接口。k8s通过CRI对容器进行操作，创建、启停容器等。安装kubeadm时会自动安装cri-tool。
从v1.6.0起，Kubernetes开始允许使用CRI。默认的容器运行时是Docker。其他的容器运行时有：containerd (containerd 的内置 CRI 插件)、cri-o、frakti、rkt。
CNI(容器网络接口)
全称"Container-Network-Interface"，各种网络插件(network-plugin)，如flannel、GCE等实现了该接口。cni用于给pod分配ip，用来划分网段，用来分配子网，用来管理k8s集群内部的网络模型。其配置文件里包含"--pod-network-cidr"参数，该参数表示用"cidr"(计算机网络基础的知识)给pod分配ip，参数的数值表示ip的前缀，比如flannel官方配置文件中的默认值为10.244.0.0/16，把10.244.0.0转换成二进制表示，取前面16位，即为给pod分配的ip的前缀。
更多资料:
k8s组件简介
Kubectl(集群控制器)
kubectl全称"Kubernetes-Controller"，运行于master节点，kubectl更像是“kubernetes-client”，类似于k8s的客户端，是k8s的控制工具，是一个命令行工具，是用户管理k8s集群的接口，负责把用户的指令传给API Server，用于集群中资源的增删查改，注意，kubeclt只是个交互接口，并不负责实际上的资源的增删查改。
在k8s中的所有内容都被抽象为“资源”，如Pod、Service、Node等都是资源。“资源”的实例可以称为“资源对象”，如某个具体的Pod、某个具体的Node。k8s中的资源有很多种，kubectl可以通过配置文件来创建这些“资源对象”，配置文件更像是描述对象“属性”的文件，配置文件格式可以是“JSON”或“YAML”，不过常用的是“YAML”。
更多资料:
Kubelet(节点代理)
运行在worker节点上，在使用kubeadm初始化集群时，master节点也需要kubelet。Kubelet全称"Kubernetes-Lifecycle-Event-Trigger"，也是Kubernetes中最主要的控制器，kubelet被称为"Node Agent"，意思是“节点上的代理”。如果说kubectl是决策者，那么kubelet相当于是管理者、执行者；如果说kubectl是总裁，那么kubelet就是各个分公司的总经理。
kubelet的主要工作如下:
-
pod管理：kubelet会监测本节点上pod、container的健康，出错时会根据配置文件的重启策略，对pod、container进行重启。 kubelet还会定期通过API Server获取本节点上的pod、container状态的期望值，然后调用容器运行时接口，对container进行调度，以达到期望状态。
-
资源监控：kubelet监控本节点资源使用情况，定时向master报告，知道整个集群所有节点的资源情况，对于pod的调度和正常运行至关重要。
API Server(网关)
API Server运行在master节点。对于整个k8s集群，可以把kubectl看做前端，看作集群管理员与k8s集群交互的接口。API Server则相当于后端的"Controller"，负责对各个组件(包括kubectl)发来的请求进行分发、处理。各个组件都直接与API Server进行通信，也只能与API Server通信。
API Server提供了集群管理的接口，提供了资源的增删查改的接口，这个接口也可以直接说是API（web开发中的“API”）。值得一提的是，这些API都是是RESTful风格的API，这与k8s“万物皆资源”的理念相符。
另外，API Server也作为集群的网关。默认情况，客户端通过API Server对集群进行访问时，客户端需要通过认证，并使用API Server作为访问Node和Pod（以及service）的堡垒和代理/通道。
Etcd(集群信息存储)
运行在Master节点。etcd与zookeeper相似但又不同，在分布式中经常会见到，是一个键值存储仓库，用于配置共享和服务发现。接着上面讲的，etcd相当于后端中的数据库，用于存储集群中的所有状态，包括各个节点的信息，集群中的资源状态等等。etcd的watch机制可以在信息发生变化时，快速的通知集群中相关的组件。
Scheduler(调度器)
运行在Master节点。scheduler组件为容器自动选择运行的主机(node)。依据请求资源的可用性，服务请求的质量等约束条件，scheduler监控还未绑定到node的pod，对其进行绑定。Kubernetes也支持用户自己提供的调度器，Scheduler负责根据调度策略自动将Pod部署到合适Node中，调度策略分为预选策略和优选策略，Pod的整个调度过程分为两步：
1）预选Node：遍历集群中所有的Node，按照具体的预选策略筛选出符合要求的Node列表。如没有Node符合预选策略规则，该Pod就会被挂起，直到集群中出现符合要求的Node。
2）优选Node：预选Node列表的基础上，按照优选策略为待选的Node进行打分和排序，从中获取最优Node。
Controller-Manager(管理控制中心)
运行在Master节点。Controller-Manager用于执行大部分的集群层次的功能，它既执行生命周期功能(例如：命名空间创建和生命周期、事件垃圾收集、已终止垃圾收集、级联删除垃圾收集、node垃圾收集)，也执行API业务逻辑（例如：pod的弹性扩容）。控制管理提供自愈能力、扩容、应用生命周期管理、服务发现、路由、服务绑定和提供。Kubernetes默认提供Replication Controller、Node Controller、Namespace Controller、Service Controller、Endpoints Controller、Persistent Controller、DaemonSet Controller等控制器。
Controller-Manager负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。
