云原生

Controller Manager Controller Manager 是控制平面的一个重要组件，负责维护 Kubernetes 集群的整体状态。 流程： 在集群中 Controller Manager 主要做以下几件事情： 监听： Controller Manager 通过 API Server 监听集群中的资源状态变化。当资源状态发生变化时，Controller Manager 会收到通知。 决策： Controller Manager 会根据资源的定义和状态做出决策。如果一个 Deployment 的 Pod 数量低于预期，Controller Manager 会创建新的 Pod。 执行： Controller Manager 会根据决策，执行相应的操作。例如，如果要创建新的 Pod，Controller Manager 会调用 API Server 来创建 Pod。 常见的 Controller Kubernetes 中内置了许多 Controller，当资源状态发生变化时，Controller Manager 会通知这些 Controller 做出决策和执行操作。 Deployment Controller：负责部署和管理 Pod 副本。 ReplicaSet Controller：负责管理 Pod 副本的数量。 DaemonSet Controller：确保每个节点都运行指定的 Pod。 Job Controller：负责执行一次性任务。 CronJob Controller：负责按照指定的频率执行任务。 StatefulSet Controller：确保 Pod 的顺序性和持久性。 Cloud Controller Manager ...

概述 kube-scheduler 是 Kubernetes 集群的核心组件之一，它负责为新创建的 Pods 分配节点。它根据多种因素进行决策，包括： 资源需求和限制：考虑每个 Pod 请求的资源量（如 CPU 和内存）以及节点上可用的资源。 亲和性和反亲和性规则：根据 Pod 的亲和性设置选择最适合的节点。 健康检查：确保选择的节点健康且能够运行 Pod。 负载均衡：尽量平衡集群中各个节点的负载。 使用 limits 和 reuqests 在部署对象中的 spec 中常常会见到关于 limits 和 requests 的声明 ，例如： apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx resources: limits: memory: 1Gi cpu: 1 requests: memory: 256Mi cpu: 100m 这里的 limits 和 requests 是与 Pod 容器资源管理相关的两个关键概念： Limits：指定容器运行时能够使用的最大资源量 Requests：指定容器启动时最低需要的资源量 limits 和 requests 跟 scheduler 有什么关系 ？ ...

概述 etcd 是一个基于 Raft 协议实现。开源的、分布式的键值存储系统。主要用于在分布式系统中提供强一致性和高可用性的数据存储。etcd 在 Kubernetes 中的作用如下： 集群状态数据存储：集群配置，集群状态信息等 保证集群一致性和高可用：多实例的数据同步 服务发现和配置共享 集群数据备份和恢复 作为 Kubernetes 的核心组件，etcd 为集群的稳定性、可靠性和一致性提供了支撑。 安装 命令行启动 安装参考官方文档 etcd install 指引即可，安装后验证： $ etcd --version 输出： etcd Version: 3.5.10 Git SHA: 0223ca52b Go Version: go1.21.3 Go OS/Arch: darwin/arm64 phoenix@xiaobindeMacBook-Pro ~ % etcd 在终端启动 etcd： $ etcd 输出： {"level":"warn","ts":"2023-11-23T06:59:49.265098+0800","caller":"embed/config.go:676","msg":"Running http and grpc server on single port. This is not recommended for production."} {"level":"info","ts":"2023-11-23T06:59:49.265318+0800","caller":"etcdmain/etcd.go:73","msg":"Running: ","args":["etcd"]} {"level":"info","ts":"2023-11-23T06:59:49.265352+0800","caller":"etcdmain/etcd.go:100","msg":"failed to detect default host","error":"default host not supported on darwin_arm64"} {"level":"warn","ts":"2023-11-23T06:59:49.265361+0800","caller":"etcdmain/etcd.go:105","msg":"'data-dir' was empty; using default","data-dir":"default.etcd"} #..... 容器启动 在容器中启动 etcd 实例： ...

安装说明 通过 docker desktop 可以安装适用于单机和开发环境单机版的 K8S，如果 docker desktop 无法启动 Kubernates 通过以下方式解决： 一：添加国内镜像源 为 Docker 的 daemon.json 添加配置： { "registry-mirrors": [ "https://docker.mirrors.ustc.edu.cn", "https://registry.docker-cn.com" ] } 二：通过脚本下载 Kubernetrs 所需要的镜像 在 GitHub 中的 k8s-for-docker-desktop 项目中下载 Kubernetes 版本对应的分支，然后执行脚本即可，启动完成后，验证 K8S 集群状态： $ kubectl cluster-info $ kubectl get nodes $ kubectl describe node 理解 Pod 先通过一个简单的示例理解 Pod，Pod 是 Kubernetes 中的基本部署单元，这里看看如何用 Pod 创建一个 nginx 服务。使用 kubectl 命令部署一个 nginx 的服务： $ kubectl create deployment nginx-arm --image=nginx 创建部署后，您可以使用以下命令检查 Pod 的状态： ...

本篇分享主要围绕以下 4 个主题进行： 什么是云原生 ？ 为什么要用云原生架构 ？ 微服务的概念 微服务的技术选型 什么是云原生 ？ 云计算和云原生 云计算不同于传统的自建机房，云计算就是将计算的抽象为基础设施然后通过网络分发，得益于云计算的无限扩展能力，使得“云计算”就像自来水厂一样，我们可以随时接水，并且不限量，按照自己家的用水量，付费给自来水厂就可以。以下云计算的五个基本特征。 以下是一些目前比较主流的公有云厂商： 云原生顾名思义，就是基于云计算特性所设计的应用服务，得益于云计算快速发展，基于云计算特性所设计的云原生应用相比传统的单体应用在安全性，扩展性，快速迭代，运维等各方便都有巨大的领先优势。云原生并不是指某一种技术，它是一种架构设计理念，只要符合这种架构设计理念的应用，都可以称为 云原生应用， 看看 CNCF 官方对于云原生的定义： 容器云技术的发展 云原生是依赖容器作为技术技术来实现的，但是容器并不是什么新潮技术，以下是容器云技术的发展历史，其中有几个关键的历史节点 早在 06 年的时候 Amazon 基于容器技术构建的 IaaS 平台 AWS，成为所有云计算厂商的鼻祖，由于技术领先的优势 AWS 现在依然也是云计算行业老大 13 年 Docker 的诞生进一步简化容器技术的使用门槛，Docker 公司自以为掌握云时代的核心技术，开始野心勃勃的有意挑战传统的云计算大厂例如 RedHat，Google 的江湖地位，公司股价也是一骑绝尘，却不料被 RedHat 联合 Google 发布的 Kubernetes 击溃，Kubernetes 的成功让大家以为容器技术并非云时代的核心技术，容器编排 才是核心技术。（备注：2020 年 K8S 官方宣布只要满足 K8S CRI 接口的容器均可以被 K8S 进行编排，Docker 被时代抛弃） 2015 年借助 Kubernetes 的成功，Google 宣布成立 CNCF 基金会，这是云原生时代的代表性的组织。致力于完善云时代的基础设施，帮助开发者构建更出色的产品 下图是 CNCF 的全景图： ...

最近几年微服务很火，大家都在建设微服务，如果不懂点微服务相关的技术，都不好意思跟同行打招呼了，也见过身边很多人在微服务踩过很多坑，我从 16 年开始接触微服务，有多家大型企业的微服务分布式系统的架构经验，所以就打算跟大家做一期关于微服务的分享，不过微服务和涉及的分布式计算非常的复杂，绝非是一篇文章就可以讲清楚的，本文只是从最简单的概念的基本使用带你入门，如果后续还有兴趣的话，可以查阅相关的文献和技术书籍去深入学习 本文的微服务分享以下三部分，总体大纲如下： 微服务的概念和原则（理论） Spring Cloud 如何低成本的实现微服务（实现） Spring Cloud 大型项目的架构方案（真实案例） 微服务的概念和原则 什么是微服务？ 简单举例：看军事新闻的同学应该都知道，一艘航空母舰作战能力虽然很强，但是弱点太明显，就是防御能力太差，单艘的航空母舰很少单独行动，通常航空母舰战斗群才是主要军事力量，你可以把单艘航母理解为的单体应用（防御差，机动性不好），把航母战斗群（调度复杂，维护费用高）理解为微服务。 简单讲特征就是： 单体应用：简单，脆弱（某个模块出问题，整个系统不可用），战斗力弱，维护成本低 微服务架构：复杂，健壮（某个模块出问题，不会影响系统整体的可用性），战斗力强，维护成本高 大部分的开发者经历和开发过单体应用，无论是传统的 SSM，还是现在的 SpringBoot/Rails，它们都是单体应用，那么长期陪伴我们的单体应用有什么弊端？我们是面临了什么问题，导致我们要抛弃单体应用转向微服务架构？个人总结主要问题如下： 部署成本高（无论是修改1行代码，还是10行代码，都要全量部署替换） 改动影响大，风险高，测试成本高（不论代码改动多小，成本都相同） 因为成本高，风险高，所以导致部署频率低（无法满足快速交付客户需求） 当然还有例如无法满足快速扩容，弹性伸缩，无法适应云环境特性等问题但我们不一一详谈了，以上的问题，都是微服务架构要解决的问题，至于具体是怎么解决的，我们先放到后面再聊 解决什么问题，又引入了什么问题？ 我们先看看微服务能带给我们什么？微服务架构的特点： 针对特定服务发布，影响小，风险小，成本低 频繁发布版本，快速交付需求 低成本扩容，弹性伸缩，适应云环境 我们知道一个朴素的理念，没有任何事物是完美的，任何东西都有两面性，有得必有失那么在选择微服务在解决了快速响应和弹性伸缩的问题同时，它又给我们带来了什么问题？个人总结如下： 分布式系统的复杂性 部署，测试和监控的成本问题 分布式事务和 CAP 的相关问题 系统应用由原来的单体变成几十到几百个不同的工程，会所产生例如包括服务间的依赖，服务如何拆封，内部接口规范，数据传递等等问题，尤其是服务拆分，需要团队熟悉业务流程，懂得取舍，要保证拆分的粒度服务既符合“高内聚，低耦合”的基本原则，还要兼顾业务的发展以及公司的愿景，要还要说服团队成员为之努力，并且积极投入，在多方中间取得平衡。 对于分布式系统，部署，测试和监控都需要大量的中间件来支撑，而且中间件本身也要维护，原先单体应用很简单的事务问题 ，转到分布式环境就变得很复杂，分布式事务是采用简单的重试+补偿机制，还是采用二阶段提交协议等强一致性方法来解决，就要取决对业务场景的熟悉加上反复的权衡了，相同问题还包括对 CAP 模型的权衡，总之微服务对团队整体的技术栈水平整体要求更高 微服务有应该遵循哪些原则？ 古人云：兵马未动，粮草先行。建设微服务是需要建立长远规划，不是像写 CMS 那样建好数据库表，然后就开始干活，这样十有八九是会失败的。我们要进行微服务改造前，架构师要提前做好规划，我们把这里分为三步，前期阶段，设计阶段，技术阶段 前期阶段，大致要做好如下事情： 和多方充分沟通，确保能符合客户和组织的需求，并且得到认同 和团队沟通，让队友（开发/测试/运维）理解，并且积极投入 和业务部门沟通，指定版本计划和上线时间 设计阶段，参考 Sam Newman 的著作《微服务设计》，单微服务必须要满足以下的条件，才符合微服务的基本要求： 标准的 REST 风格接口（基于 HTTP 和 JSON 格式） 独立部署，避免共享数据库（避免因为数据库而影响整个分布式系统） 业务上的高内聚，减少依赖（从设计上要避免服务过大或者太小） 庞大的分布式系统，需要强大基础设施来支撑，微服务涉及哪些基础设施？ CI/CD和自动化（分布式系统几乎不可能通过人工手动发布） 虚拟化技术（要保证微服务运行环境隔离，目前行业主流的是使用 Docker 容器） 日志聚合，全链路监控（高度可观察和分析诊断问题） 说了那么多，那什么样的情况下，你的团队不适合建设微服务？（请勿对号入座） 开发团队不具备自主性，所在组织对开发团队限制非常多（具体请参考 康威定律） 团队不熟悉业务，无法识别出服务的边界，进行合理的拆分（请参考 DDD 领域驱动设计） 微服务设计其实是很早就有的设计思想，因为随着虚拟化技术的崛起，微服务可以低成本的实现，所以也开始流行和兴起。 ...