K8S旅途-摘读自K8S权威指南

1.1 Kubernetes前生

Kubernetes缩写K8S，是goole使用了十几年Borg的开源版本，borg是goole内部使用的大规模集权管理系统，基于容器技术实现资源管理自动化，以及跨多个数据中心的资源利用率最大化的一个令人叹服的编排系统。

K8S是一个全新的基于容器技术的分布式架构方案，是容器云的代表，pass平台的重要底层框架，也是目前云原生的核心，服务网格service mesh，无服务器架构severless等技术都基于K8S来实现，这也奠定了K8S在云架构的超然地位。

在系统设计中遵循K8S的设计思想，那么传统架构中那些与和业务关联不大的底层代码或者模块功能，就可以避免去花费精力去解决负载均衡和部署的问题，因为K8S已经为你准备了完整方案，不必考虑去开发一个复杂的治理框架，服务监控，故障模块开发。大大减少了运维难度，和运维成本。

K8S是一个开放平台，不限于任何语言，不限定接口，java，go，c++，python等编写的服务都可以映射为K8S的service，并通过标准的TCP通信交互，K8S平台对编程语言，框架，中间件，没有侵入性，容易进行升级并迁移到K8S上。

K8S提供了完整的工具，涵盖了开发，部署，测试，运维监控等，K8S是一个全新的基于容器技术的分布式架构方案，是一个一站式的完备的分布式系统开发和支撑平台。

Service概念：

在K8S中service是分布式集群架构的核心。一个service对象拥有如下特征。

 

 唯一指定的名称（例如mysql-server）

  一个虚拟IP地址（ClusterIP地址）和端口号，是集群内部通信的IP，若需要与外界通信，需要进行映射。

 能够提供某种远程服务

 能够将客户端对服务的访问请求转发到一组容器应用上。

 

Service服务进程一般基于socket通信方式进行对外提供服务，例如。Redis，mencached，mysql，web server，或者是实现了某个业务的特定tcp server进程。虽然一个server通常由多个相关服务进程提供服务，每个服务进程都有一个独立的Endpoint(ip+port)访问点，但K8S能够让我们通过service（clusterip+service port），kubernetes内建的透明负载均衡和故障恢复机制，无论后端有多个具体的服务进程，也不管某个服务进程是因为发生故障而被重新部署到其他机器。都不会影响对服务的正常调用。另外，service本身一旦创建就不会变化，意味着容器服务进程的IP虽然一直变化，但是serviceIP没有变就不会影响访问。

容器提供了强大的隔离功能，所以我们有必要把为service提供服务的这组进程放入容器中隔离，为此K8S设计了pod的对象，将每个服务进程都包装到相应的pod中，使其成为pod中运行的一个容器，为了建立service和pod的关联，kubernetes首先给每个pod都贴上一个标签（label），比如给运行mysql的pod贴上name=mysql标签，给运行PHP的pod贴上name=php的标签，然后给相应的service定义标签选择器（label selector），例如，mysql service的标签选择器的选择条件为name=mysql，意为该service要作用于所有包含name=mysql标签的pod。巧妙解决了service与pod的关联问题。

Pod概念：

首先pod运行在一个被称为节点node的环境中，这个节点可以是物理机，虚拟机，云服务器，在一个节点上可以运行一个或者多个pod，每个pod都运行着一个特殊的被称为pause的容器，其它容器则为业务容器，这些业务容器共享pause容器的网络栈和volume挂在卷，因此它们之间的通信和数据交换更为高效，在设计时可以利用这个特性把一组紧密联系的服务进程放入同一个pod中，需要注意的是，并不是每个pod和它里面运行的容器都能被映射到service上，只有提供服务对内或对外的那组pod才会被映射为一个服务。

在集群管理方面，Kubernetes将集群中的机器划分为一个master和一些node。在master上运行着集群管理相关的一些进程：如kube-apiserver，kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理，pod调度，弹性伸缩，安全控制，系统监控和纠错等管理功能，并且都是自动完成的。

Node作为集群的工作节点，其上运行着真正的业务应用程序。在node上，kubernetes管理的最小运行单元是pod。在node上运行着kubernetes的kubelet，kube-proxy服务进程，这些服务进程负责pod的创建，启动，监控，重启，销毁，以及实现软件模式的负载均衡器。

在传统的IT系统中，服务扩容和服务升级是个难题，K8S提供了全新的解决思路，服务的扩容涉及资源分配，就是在哪个节点上进行扩容，实例部署和启动等，在传统系统中是比较麻烦且费力的。

Deployment概念

在K8S集群中，只需为需要扩容的service关联的pod创建一个deployment对象，服务扩容以及服务升级等令人头疼的问题都轻容搞定。

在一个deployment定义文件中包含三个关键信息。

目标pod的定义

目标pod需要运行的副本数量（replicas）

要监控的目标pod标签

在创建好deployment之后。Kubernetes会根据这一定义创建符合要求的pod，并且通过deployment中定义的label筛选对应的pod实例并实时监控其状态和数量，如果实力数量少于定义的副本数量，则会根据在deployment对象中定义的pod模板创建一个新的pod，然后将这个pod调度到合适的node上，直到pod数量达到预期，这个过程是完全自动化的。有了deployment，服务扩容变成了很简单的事，只需要修改deplyment中的副本数量就可以实现。升级操作也是经过配置deplyment完成。

 

 

 

 

 

1.2 .使用K8S的原因

使用Kubernetes的理由很多，最重要的理由是，IT行业从来都是由新技术驱动的。 Kubernetes是软件领域近几年来最具创新的容器技术，涵盖了架构、研发、部署、运维等全系列软件开发流程，不仅对互联网公司的产品产生了极大影响，也对传统行业的IT技术产生了越来越强的冲击。基于Kubernetes的新一代容器架构已成为互联网产品及大规模系统的必选方案。2020年3月，虚拟化技术巨头VMware发布了使用Kubernetes重新打造的全新vSpbere7，向全球宣告了其拥抱Kubernetes的决心，堪称虚拟化技术十年来最 大的一次演进。vSpbere7通过底层重构，使得用户能够以ESXi管理VM虚拟机的方式来运用Kubernetes的能力。毫无疑问，VMware的这一举动将对IT行业带来重大影响，也宣告了以Kubernetes为核心的容器技术取代、融合虚拟机技术的时代正在加速到来。

如今，数百家厂商和技术社区共同构建了非常强大的云原生生态，市面上几乎所有提供云基础设施的公司都以原生形式将 Kubernetes作为底层平台，可以预见，会有大量的新 系统选择 Kubernetes，不论这些新系统是运行在企业的本地服务器上，还是被托管到公有 云上。阿里云容器服务 Kubernetes 版 ACK( Alibaba Cloud Container Service for Kubernetes ) 是全球首批通过 Kubernetes 一致性认证的服务平台。据公开资料，截至 2020 年，在 阿里云的 ACK 上，已经运行着上万个用户的 Kubernetes 集群。而腾讯自研的 TKEx 容器平台的底层也使用了 Kubernetes原生技术，服务于腾讯的各种业务系统，包括腾讯会议、 腾讯课堂、 QQ 及腾讯看点等，目前这些业务已运行的 Kubernetes 集群规模达到几百万 CPU 核数。百度云容器引擎（Cloud Container Engine ）也采用 Kubernetes作为容器集群管理系统，于 2019 年年底也得到了云原生计算基金会的官方认证，而在更早的 2018 年，百度的深度学习平台 PaddlePaddle 也宣布支持 Kubernet町，并在当年成为 Kubernetes 官方唯一支持的深度学习框架。华为早在 Kubernetes 刚开源时就以社区创始成员及自金会员的身份加入其中， 华为云的容器引擎（CCE）也基于 Kubemetes实现，同时补齐了完整时应用开发、 交付与运维流程，为客户提供完整的一站式云上应用生命周期管理方案。

使用 Kubernetes 会收获哪些好处呢？

首先，可以“轻装上阵”地开发复杂系统。以前需要很多人（其中不乏技术达人）一 起分工协作才能设计、实现和运维的分布式系统，在采用Kubernetes解决方案之后，只需 一个精悍的小团队就能轻松应对。在这个团队里，只需一名架构师负责系统中服务组件的架构设计，几名开发工程师负责业务代码的开发，一名系统兼运维工程师负责Kubemetes的部署和运维， 因为Kubemetes已经帮我们做了很多。

其次，可以全面拥抱以 微服务架构为核心思想的新一代容器技术的领先架构，包括基础的微服务架构 ． 以及增强的微服务架构（如服务网格、 无服务器架构等）。 微服务架构的核心是将一个巨大 的单体应用分解为很多小的相互连接的微服务，一个微服务可能由多个实例副本支撑 ， 副本的数量可以随着系统的负荷变化进行调整。 微服务架构使得每个服务都可以独立开发、 升级和扩展，因此系统具备很高的稳定性和快速迭代能力，开发者也 可以 自由选择 开发技术。 谷歌、 亚马逊、eBay、 Netflix等大型五联网公司都采用了微服务架构，谷歌更是将微服务架构的基础设施直接打包到Kubernetes 解决方案中，让我们可以 直接应用微服务架构解决复杂业务系统的架构问题。

再次，可以随时随地将系统整体 “搬迁” 到公有云上。 Kubernetes最初的设计目标就是让用户的应用运行在谷歌自家的公有云GCE 中，华为云（CCE）、 阿里云（ACK） 和腾讯云（TKE）全部支持Kubemetes集群，未来会有更多的公有云及私有云支持Kubemetes。除了公有云，私有云也大量采用Kubernetes架构。 在私有云与公有云融合的混合云领域， Kubernetes也大显身手。在Kubernetes和容器技术诞生之前，要实现多云和混合云是很困难的，应用开发商需要针对每个云服务商进行定制化开发，导致迁移云服务商时 从基础架构到应用程序层面都需要做出相应的改动和适配。有了Kubernetes之后，用户本地的私有 云（数据中心）可以 与云服务商的Kubernetes集群保持一致的接口，这样应用程序在大 部分情况下就不需要与具体的云服务商直接绑定了。

然后，Kubemetes内建的服务弹性扩容机制可以让我们轻松应对突发流量。在服务高峰期，我们可以选择在公有云中快速扩容某些Service的实例副本以提升系统的吞吐量， 这样不仅节省了公司的硬件投入，还大 大 改善了用户体验。 中国铁路总公司的12306购票系统，在客流高峰期（如节假日） 就租用了阿里云进行分流 。

最后，Kubemetes系统架构超强的横向扩容能力可以让我们的竞争力大 大提升。 对于 互联网公司来说，用户规模等价于资产， 因此横向扩容能力是衡量互联网业务系统竞争力的关键指标。 我们利用 Kubernetes 提供的工具，不用修改代码， 就能将一个Kubernetes 集群从只包含几个Node的小集群平滑扩展到拥有上百个Node的大集群，甚至可以在钱完成集群扩容。 只要微服务架构设计得合理，能够在多个云环境中进行 弹性伸缩，系统就 能够承受大量用户并发访问带来的巨大压力。