2023年6月30日发(作者：)

K8s的⼯作原理title: Kubernetes之初探subtitle: K8s的⼯作原理date: 2018-09-18 18:26:37K8s概述我清晰地记得曾经读到过的⼀篇博⽂，上⾯是这样写的，“云端教⽗AWS云端架构策略副总裁Adrian Cockcroft曾指出，两者虽然都是运⽤容器技术，但最⼤的差异是，Docker是要解决应⽤程序开发（Developing）问题，⽽Kubernetes是要解决更上层的应⽤程序运维问题（Operation）。开发问题是早期的痛点，但随着企业越来越依赖容器技术，内部应⽤越来越多是云原⽣应⽤时，运维会是企业IT的新痛点。”⼤佬的⼀番话，明确地指出K8S的⽣存⼟壤！学习⼀项技术，除了需要明确这项技术的应⽤场景和发展⽅向之外，最主要的是理解她的⼯作原理。K8s的⼯作原理1. 什么是K8sKubernetes（k8s）是跨主机集群的⾃动部署、扩展以及运⾏应⽤程序容器的开源平台，这些操作包括部署，调度和节点集群间扩展。⼤⼆下学期我曽⽤过Docker容器技术部署容器，经历过compose的变种，对于应⽤版本之间的兼容性问题深恶痛绝。我们可以将Docker看成Kubernetes内部使⽤的低级别组件。Kubernetes不仅仅⽀持Docker，还⽀持Rocket（没有接触过），这是另⼀种容器技术。wikipedia给出的定义：K8s是⽤于⾃动部署、扩展和管理容器化（containerized）应⽤程序的开源系统。Google设计并捐赠给Cloud NativeComputing Foundation（今属Linux基⾦会）来使⽤的。它⽀持⼀系列容器⼯具, 包括Docker等。CNCF于2017年宣布⾸批Kubernetes认证服务提供商（KCSPs），包含IBM、华为、MIRANTIS、inwinSTACK迎栈科技等[5]服务商。在《Kubernetes权威指南（第⼆版）》中给出的定义：她是⼀个全新的基于容器技术的分布式架构领先⽅案，她提供了强⼤的⾃动化机制，系统后期的运维难度和运维成本⼤幅度降低。她是Google的⼤闺⼥的开源版本。使⽤K8s提供的解决⽅案，可以节省⼤概30%的开发成本，可以将精⼒更加集中于业务本⾝。2. ⽤法使⽤Kubernetes可以：⾃动化容器的部署和复制随时扩展或收缩容器规模将容器组织成组，并且提供容器间的负载均衡很容易地升级应⽤程序容器的新版本提供容器弹性，如果容器失效就替换它，等等...3. 核⼼概念1) 集群在集群管理⽅⾯，K8s将集群中的机器划分为⼀个Master节点和⼀群⼯作节点Node。Master节点上运⾏着集群管理相关的⼀组进程kube-apiserver、kube-controller-manager和kube-scheduler。这些进程⾃动化实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能。上图可以看到如下组件，使⽤特别的图标表⽰Service和Label：Kubernetes Master（Kubernetes主节点）Node（节点）PodContainer（容器）Label(label)（标签）Replication Controller（复制控制器）Service（enter image description here）（服务）2) Kubernetes MasterMaster指的是集群控制节点。每个K8s集群⾥需要有⼀个Ms节点负责整个集群的管理和控制。Kubernetes Master提供集群的独特视⾓，并且拥有⼀系列组件。Kubernetes API Server（kube-apiserver），侍卫⼤统领！提供HTTP Rest接⼝的关键服务进程，是K8s⾥所有资源的增删改查等操作的唯⼀⼊⼝，也是集群控制的⼊⼝进程。API Server提供可以⽤来和集群交互的Rest端点。Kubernetes Controller Master（kube-controller-manager）掌印⼤太监，⼤总管！K8s⾥所有资源对象的⾃动化控制中⼼。Kubernetes Scheduler（kube-scheduler），御马间的调度室！负责资源调度（Pod调度）的进程。创建和复制Pod的ReplicationController。3) Node节点（上图橘⾊⽅框）是物理或者虚拟机器，作为Kubernetes worker，通常称为Minion。每个节点都运⾏如下Kubernetes关键组件。(1) Kubelet：与Master节点协作，是主节点的代理，负责Pod对应容器的创建，启动，停⽌等任务。默认情况下Kubelet会向Master注册⾃⼰。Kubelet定期向主机点汇报加⼊集群的Node的各类信息。(2) Kube-proxy：Kubernetes Service使⽤其将链接路由到Pod，作为外部负载均衡器使⽤，在⼀定数量的Pod之间均衡流量。⽐如，对于负载均衡Web流量很有⽤。(3) Docker或Rocket：Kubernetes使⽤的容器技术来创建容器。4) PodPod是K8s最重要也是最基础的概念！每个Pod都有⼀个特殊的被称为“根容器”的Pause容器，此容器与引⼊业务⽆关并且不易死亡。且以它的状态代表整个容器组的状态！Pause容器对应的镜像属于K8s平台的⼀部分，除了Pause容器，每个Pod还包含⼀个或多个⽤户业务容器。Pod其实有两种类型：普通的Pod及静态Pod（static Pod）,static Pod并不存放在Kubemetes的eted存储⾥，⽽是存放在某个具体的Node上的⼀个具体⽂件中，并且只在此Node上启动运⾏。⽽普通的Pod⼀旦被创建，就会被放⼊到etcd中存储，确后会被KubernetesMaster调度到某个具体的Node上并进⾏绑定（Binding），随后该Pod被对应的Node上的kubelet进程实例化成⼀组相关的Docker容器并启动起来。在默认情况下，当Pod⾥的某个容器停⽌时，Kubemetes会⾃动检测到这个问题并且重新启动这个Pod（重启Podel）的所有容器），如果Pod所在的Node完机，则会将这个Node上的所有Pod重新调度到其他节点上。Pod（上图绿⾊⽅框）安排在节点上，包含⼀组容器和卷。同⼀个Pod⾥的容器共享同⼀个⽹络命名空间，可以使⽤localhost互相通信。Endpoint（Pod IP + ContainerPort） pod ip：⼀个Pod⾥多个容器共享Pod IP地址。K8s要求底层⽹络⽀持集群内任意两个Pod之间的TCP/IP直接通信，使⽤虚拟⼆层⽹络技术（Flannel（没有接触过 ），OpenvSwitch）实现。在Vmware中类似的⼆层交换技术是VSwitch，当然了，现在整个数据中⼼⽹络⼆层逐步从vSwitch—>OpenvSwitch5) LableLable类似Docker中的tag，⼀个是对“特殊”镜像、容器、卷组等各种资源做标记，⼀个是attach到各种诸如Node、Pod、Server、RC资源对象上。不同的是Lable是⼀对键值对！Lable类似Tag，可使⽤K8s专有的标签选择器（Label Selector）进⾏组合查询。6) Replication ControllerReplication Controller，简称RC，她⽤来⼲啥呢？就是通过她来实现Pod副本数量的⾃动控制！RC确保任意时间都有指定数量的Pod“副本”在运⾏。如果为某个Pod创建了RC并且指定3个副本，它会创建3个Pod，并且持续监控它们。如果某个Pod不响应，那么ReplicationController会替换它，保持总数为3。如果之前不响应的Pod恢复了，现在就有4个Pod了，那么Replication Controller会将其中⼀个终⽌保持总数为3。如果在运⾏中将副本总数改为5，Replication Controller会⽴刻启动2个新Pod，保证总数为5。还可以按照这样的⽅式缩⼩Pod，这个特性在执⾏滚动升级时很有⽤。注意：删除RC，不会影响该RC已经创建好的Pod。在逻辑上Pod副本和RC是解耦和的！创建RC时，需要指定Pod模板（⽤来创建Pod副本的模板）和Label（RC需要监控的Pod标签）。由Replication Controller衍⽣出Deployment，与RC相似90%，⽬的是更好地解决Pod编排。暂时不讨论。Horizontal Pod Autoscaler，简称HPA，Pod横向⾃动扩容智能控件。与RC，Deployment⼀样，也属于K8s的⼀种资源对象。她的实现原理是通过追踪分析RC控制的所有⽬标Pod的负载变化情况，来确定是否针对性地调整⽬标Pod的副本数。7) Service微服务架构中的⼀个“微服务”，她是正真的新娘，⽽之前的Pod，RC等资源对象其实都是嫁⾐。每个Pod都会被分配⼀个单独的IP地址，⽽且每个Pod都提供了⼀个独⽴的Endpoint（Pod lP + ContainerPort）以被客户端访问，现在多个Pod副本组成了⼀个集群来提供服务，客户端要想访问集群，⼀般的做法是部署⼀个负载均衡器（软件或硬件），为这组Pod开启⼀个对外的服务端⼝如8000端⼝，并且将这些Pod的Endpoint列表加⼊8000端⼝的转发列表中，客户端就可以通过负载均衡器的对外IP地址 + 服务端⼝来访问此服务，⽽客户端的请求最后会被转发到哪个Pod，则由负载均衡器的算法所决定。K8s的server定义了⼀个服务的访问⼊⼝地址，前端（Pod）通过⼊⼝地址访问其背后的⼀组由Pod副本组成的集群实例，service与其后端Pod副本集群之间通过Label Selector 实现“⽆缝对接”。可以将Server抽象成特殊的扁平的双向管道，Service借助Label Selector保证了前端容器正确可靠地指向对应的后台容器。 RC的作⽤保证了Service的服务能⼒和服务质量始终处于预期的标准。Kubemetes也遵循了上述常规做法，运⾏在每个Node上的kube-proxy进程其实就是⼀个智能的软件负载均衡器，它负责把对Service的请求转发到后端的某个Pod实例上，并在内部实现服务的负载均衡与会话保持机制。但Kubernetes发明了⼀种很巧妙⼜影响深远的设计：Service不是共⽤⼀个负载均衡器的IP地址，⽽是每个Service分配了⼀个全局唯⼀的虚拟IP地址，这个虚拟IP被称为ClusterIP。这样⼀来，每个服务就变成了具备唯⼀IP地址的“通信节点”，服务调⽤就变成了最基础的TCP⽹络通信问题。Pod的Endpoint地址会随着Pod的销毁和重新创建⽽发⽣改变，因为新Pod的IP地址与之前旧Pod的不同。⽽Service⼀旦创建，Kubemetes就会⾃动为它分配⼀个可⽤的Cluster IP，⽽且在Service的整个⽣命周期内，它的ClusterIP不会发⽣改变。于是，服务发现这个棘⼿的问题Kubemetes的架构⾥也得以轻松解决：只要⽤Service的Name与Service的Cluster IP地址做⼀个DNS域名映射即可完美解决问题。版本问题初始版本开发状态活跃编程语⾔Go操作系统跨平台类型⽹站集群管理许可协议Apache许可证 2.0源代码库/kubernetes/kubernetes2014年6⽉7⽇，4年前稳定版本1.10.3（2018年5⽉21⽇，3个⽉前)