k8s微服务架构（k8s是什么意思）

本文目录

• k8s是什么意思
• 资深架构师分享：1 天落地的 Kubernetes 容器化方案
• k8s系列文章2: 关于k8s
• k8s的主要功能
• 微服务架构总览

k8s是什么意思

k8s是为容器服务而生的一个可移植容器的编排管理工具。
k8s是为容器服务而生的一个可移植容器的编排管理工具，越来越多的公司正在拥抱k8s，并且当前k8s已经主导了云业务流程，推动了微服务架构等热门技术的普及和落地，正在如火如荼的发展。
从架构设计层面，我们关注的可用性，伸缩性都可以结合k8s得到很好的解决，如果你想使用微服务架构，搭配k8s，绝对完美，再从部署运维层面，服务部署，服务监控，应用扩容和故障处理，k8s都提供了很好的解决方案。

资深架构师分享：1 天落地的 Kubernetes 容器化方案

Kubernetes 是趋势

Kubernetes 是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

Kubernetes是一个完备的分布式系统支撑平台，具有完备的集群管理能力，多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes提供完善的管理工具，涵盖了包括开发、部署测试、运维监控在内的各个环节。

2016、2017年开始，各大互联网厂商就已经进行了各种容器化 + Kubernetes的尝试，各种实践证明 Kubernetes 越来越成熟。

Kubernetes 门槛高

然而，Kubernetes 在更大范围内落地的过程却困难重重，原因主要在于其过高的学习门槛：

• 基础知识要求多，Linux、网络、Docker等；

• 集群安装管理复杂；

• Kubernetes 的配置文件 YAML 冗长，对象类型繁多、关联关系复杂

Kuboard 助力

Kuboard 从以下几方面解决 Kubernetes 落地的难题：

Kubernetes 安装手册

通过对 Kubernetes 安装步骤的反复研究，提供了精简的 Kubernetes 安装手册，并且听取网友实际安装过程中的反馈，多次修改和优化，逐渐形成经过检验的、简洁的 Kubernetes 安装手册。

图形化管理界面

提炼 Kubernetes 各核心概念之间的关系，帮助用户理解如何配置 Kubernetes，并以此为依据设计了 Kuboard 工作负载器。使用 Kuboard，用户无需手工编写和维护冗长的 YAML 文件，配合 Kuboard 提供的其他辅助手段，完全通过图形界面就可以实现微服务的部署和维护。

Spring Cloud 微服务部署实战案例

Kuboard 提供 Spring Cloud 在 Kubernetes 上部署的实战案例分析，手把手帮助技术团队完成 Spring Cloud 微服务在 Kubernetes 上的部署和维护。

免费自助

这么好的东西卖多少钱？您完全无需为了使用此方案而进入漫长的商务谈判、内部审批流程。

***隐藏网址*** 完全免费 ，已经有许多技术团队参考这些资料，结合其已有经验，顺利地完成 Kubernetes + 微服务的落地交付。碰到问题时，您也可以通过 Kuboard 社群获得支持， 私信回复“社群”可以免费获取技术支持跟学习资料。

k8s系列文章2: 关于k8s

    Kubernetes（简称k8s），是一个全新的基于容器技术的分布式架构领先方案。是Google保密已久的秘密武器--Borg的开源版本。Borg使用容器技术，管理着谷歌内部规模庞大的集群管理系统。2015年，Kubernetes和Borg论文被首次公开，世人第一次揭开了它神秘的面纱。从此，爱它的人对他爱不释手；恨它的人，额，有恨它的人吗？

    如果用一句话说清楚k8s的作用，那就是k8s的目的是实现资源管理的自动化，尤其是在大规模的集群中。对于运维人员，使用k8s会显著地减少工作量，因为大部分任务k8s都会自动完成。对于开发来说，可以将更多的精力放在业务逻辑的打磨上。总之，k8s提供了强大的自动化能力，系统后期的运维难度和运维成本都 显著地降低。

    1）运维难度大大降低。在一个团队中，只需要一小部分成员负责项目的部署和运维即可，其他人员可专业打磨业务逻辑。

    2）k8s可以全面拥抱微服务。微服务的核心是将一个体量巨大的系统分解为很多小的互相连接的微服务，一个微服务可能由多个实例副本支撑，副本的数量可以随着系统的负荷进行调整。k8s几乎天然支持了微服务。

    3）可以将系统随时整体搬迁到公有云上。目前，国内主流的几多云（华为云、阿里云、腾讯云）相继宣布支持k8s。同时由于k8s屏蔽了底层网络的细节，基于虚拟IP的设计思路，使得k8s与底层的硬件拓扑无关，可以无需改变运行期配置文件的情况下，对系统进行迁移。

    4）k8s具有超强的横向扩展能力。

    不积跬步，无以至千里。开始吧，搭建第一个k8s集群！

k8s的主要功能

一、什么是k8s，k8s都有什么功能？

k8s是一个docker容器管理工具

二、k8s的核心功能

k8s最适合跑微服务架构
创建一个rc yaml文件
升级 kubectl rolling-update nginx -f nginx-rc1.15.yaml --update-period=10s

这个是rc的资源升级命令        --update-period=10s这个是10.秒更新一个pod资源

回滚 kubectl rolling-update nginx2 -f nginx-rc.yaml --update-period=1s

这个是回滚的命令，如果升级的新版本有问题就马上回滚到上个稳定的版本中

service帮助pod暴露端口

创建一个service
修改nodePort范围

service默认使用iptables来实现负载均衡, k8s 1.8新版本中推荐使用lvs(四层负载均衡)

创建deployment
kubeadm安装k8s1.13 - 技术之路
namespace做资源隔离
pv: persistent volume 全局的资源 pv，node

pvc: persistent volume claim 局部的资源（namespace）pod，rc，svc

上传yaml配置文件,创建pv和pvc
file:///F:/%E6%96%B0%E5%BB%BA%E6%96%87%E4%BB%B6%E5%A4%B9/%E4%BA%91%E8%AE%A1%E7%AE%97/k8sday03/k8s%E8%AF%BE%E7%A8%8Bday3.pdf

微服务架构总览

微服务是一种基于有界上下文的，松散耦合的面向服务的架构。

什么场景下适用微服务？什么阶段时适用微服务？

设计的微服务系统的组织，其产生的架构设计应等价于组织间的沟通结构。

这句话的意思是说，原始组织之间的结构最好能映射到设计的微服务系统架构上。比如一个系统包含订单、商品、用户等功能，现实中分别由A、B、C三个小组进行开发维护，那么如果要拆分为微服务的架构，最好就能拆分为订单服务、商品服务、用户服务三个微服务，对应A、B、C三个现实的小组结构。

微服务并不是适合任何阶段，最好的方式就是随着项目的扩大或者团队的扩大时，逐步演进到微服务。因为单体应用会随着规模的扩大而逐渐增加内耗，导致生产力降低。微服务的目标是在规模扩大时，使得生产力能维持在一个稳定的水准之上。

微服务生产力超过单体的拐点，一般来说是指当团队人数规模达到百人时。当然，这也不是绝对的，需要团队负责人自己视情况进行评估。

如果在项目一开始就设计微服务的架构，一路上会遇到极大的困难与风险。比如业务模块边界的划分、无法预估的业务或者技术复杂性，这些都会耗费更多的人力和时间，甚至最终导致项目失败。

建议的方式就是由单体演进，我们可以在单体阶段不断摸索和沉淀业务和技术上的问题，随着越来越清晰的认知，再加上日渐增加的复杂度，可以考虑逐步拆分部分服务出来，朝着微服务架构的方向演进。

微服务架构中服务与服务各有不同，相互之间也应该按照层级的方式进行编排。有的与业务无关的服务天然属于底层基础服务，有的与业务有关联的服务则属于聚合了基础服务的聚合服务。

在常见的公司微服务总体架构中，一般的架构表现就如下所示：

有了各个层级的服务之后，中台的概念和战略就显得很自然。

服务注册与发现是微服务架构得以运转的核心功能，它不提供任何业务功能，仅仅用来进行服务的发现和注册，并对服务的健康状态进行监控和管理。其核心的工作原理：

现在注册中心比较多，主流的有Eureka、Consul、Zookeeper、Nacos等。

网关是整个系统对外暴露的唯一入口，它封装了系统内的所有微服务，对外看来，别人只知道也只能通过网关才可以和系统进行交互。网关对所有请求进行非业务功能的处理，然后再将请求发送给内部指定的微服务进行业务上的处理。总的来说，网关最主要的功能如下：

现在常见的网关有Kong、Zuul、Spring Cloud Gateway等；

在实际应用中，一个微服务体系架构的系统可以有多个网关用来应对不同的使用场景，比如公司内网网关、外网网关、提供给第三方调用的网关等；

微服务在启动和运行的过程中，经常会需要读取一些配置信息，这些配置信息拥有如下的特点：

如上这些特点和需求，催生了配置中心的出现。现在主流的配置中心有Spring Cloud Config、Nacos、Apollo等；

在微服务架构中，一次调用请求可能贯穿多个服务，这些服务可能是由不同的团队使用不同的技术开发而成的，如果出现调用失败需要排查问题时，如何能快速地复现调用现场，发现问题出在哪个服务哪个服务器上就成了全链路监控需要解决的问题。

全链路监控的基本原理都是：

全链路监控主流工具有CAT、Zipkin、Pinpoint、Skywalking等；

在微服务架构体系中，服务之间的调用是很频繁的，一旦某些服务出现故障或者高延迟，会很可能造成级联故障，如果客户端还在不停重试，将会加剧问题的严重性，最终导致整个系统彻底崩溃。

断路器的设计与实现有助于防止多服务之间的级联故障，允许我们构建具有容错性和高弹性的微服务架构系统，当某些服务不可用时，提供服务熔断和服务降级功能，保证系统的其它部分仍能正常运行。

断路器的三个状态和含义如下：

主流常见的断路器有Hystrix、Sentinel等；

如果使用了容器技术，那么容器编排、发布、治理就成了避不开的话题。主流的技术如下：

各大容器云厂商基本都是使用基于k8s的容器治理方案，k8s也已经成为该领域事实上的标准了。

如上是自己在极客时间App上学习《微服务架构核心20讲》的笔记，该课程一天就能学完，没有实现微服务的细节，是高屋建瓴地讲解微服务架构的蓝图，带你鸟瞰整个微服务架构，推荐学习。