**资料合集 Kubernetes**
相关链接 #
资料合集 JAVA
资料合集 Kubernetes
资料合集 其他
微服务 #
我从上海回贵阳了，17 年开始接触微服务，这种东西国内跟风很严重，当时是技术主管瞎搞，反正听上去高大上，老板开心就完事。贵阳大部分公司都在玩 spring boot+spring cloud 这一套了，怎么说呢，要熟悉起来不难的，gayhub 上找个练习+实战项目就搞定了，加油。
我们用了 kubernetes+springboot.完全不用理会 spingclound.
你用了 kubernetes，再用 springcloud 就是多余
JAVA 强大的背后不是语言的特性，而是设计模式，设计原则，这些在大型系统开发中必不可少，但是小程序，写个脚本什么的，很少用 JAVA 去做。学 JAVA 本身的语法其实用处不大，Spring 思想（设计模式），微服务架构之类的才是精华。你想深入了解可以先看微服务架构的书，然后 IPC （进程间通信）学了之后看 MIT 6.824 ，这些比学 JAVA 而言更有用。
微服务不仅是应用程序逻辑上细分，团队组织结构也要随之变化。
微服务实施中 DevOps 是一等公民，如果在 Infrastructure 上不能做到自动化，不写测试，不做 CI、CD，还是算了吧。这个我了解过国内所谓在实施微服务的，基本很少去做，靠人肉运维还是算了吧，你永远不是微服务。
微服务为容器而生，Spring Cloud 最大问题就是把微服务一些运维相关的东西耦合到应用之一，会导致写测试非常不方便。在 Spring Cloud 刚出来的时候，那时只有 Netflix 那一套，一个项目 Dropwizard 迁移过来，做了大量的 POC，最终我们只采用了 Spring Cloud 的日志跟踪，其他全部用容器（ Service Discovery, Load Balance 等）实现。
如果对微服务的一些模式有一定认知，你会发现用什么语言框架去实现都不是问题。当你可以驾驭微服务，完全可以混合使用多种语言，架框去实现。理想情况下，使用微服务可以发挥团队所有人员的天分，开发人员（一个小团队）完全可以用自己的擅长的技术去实现（ micro ） service，把产品做到极致。
你以为用了 Spring Cloud 就是微服务。
很多小团队连设计和建模都没，上来就撸服务，走都没学好就想着跑。
做微服务要是真不会分服务，建议先从单体（巨石）应用开始，核心业务域确定了之后再根据情况进行微服务拆分。
上手就来微服务设计的一般只有两类人，1. 运维开发 /中间件开发，指脱离业务域运作的； 2. 啥都不知道盲从的，完全不顾及项目成本和风险的
如果微服务 没有好的基础设施，还是不要碰的好。 我们公司是上了 k8s，但是也不会想去上 SpringCloud。
SpringBoot 足够了。虽然，拆分了。但是 开发的效率是提升了几倍。
我们没上容器化之前，运维人肉搬运 代码上线的。 运维天天被各个项目上线，烦的抽离不出来。 基本一天都安排不过来。自动化之后，基本没人找了。专心搞 服务器。
Spring Cloud==> Microservice 1.0 国内开发人员依赖 Spring 太厉害了。 K8s ===> Microservice 2.0 现在容器编排几乎是 K8s 一家独大。
以前一个海外项目 ，Spring Cloud 开始有雏形（主要是集成 Netflix 那一套）的时候就开始试用（当然我们会写 POC 进行比较），结果我们放弃了几乎所有的 Spring Cloud 项目（除了日志跟踪），当时我们认为最大的问题，它将运维的一些东西全部集成到代码，性能上成问题，而且后期运维，扩展非常不方便。像 Service Discovery，Config，Load Balance，Circuit Breaker 这些可以说用容器方便的得多， 将这些打包进 Service，本身就违背 Microservice 的初忠。每个 Service 本身就是应该集成在解决业务问题， 对于用什么技术并不重要。
k8s + istio + gRPC 全家桶解决跨语言微服务大部分问题
Kubernetes #
同类型产品？ Spring Cloud(-netflix仅维护, -alibaba)
Docker Swarm 基本公司已经不维护（业务出售了）
2013 年开源的 docker 为代表的的容器技术和以 2014 年开源的 K8s 为代表的容器编排技术
要出发周边游（以下简称要出发）是国内知名的主打「周边游」的在线旅行网站，为了降低公司内部各个业务模块的耦合度，提高开发、交付及运维效率，我们在 2017 年就基于 Spring Cloud 完成了公司内部业务微服务化的改造，并在 2019 年实现了 Spring Cloud 至 UK8S 平台的迁移。
本文从要出发的业务架构、Prometheus JVM 监控、基于 HPA 的峰值弹性伸缩、基于 Elastic 的 APM 链路跟踪及 Istio 服务治理等方面介绍了我们基于 UK8S 的 Spring Cloud 改造实践。
改造前，Spring Cloud 的业务架构如下：服务发现部分采用了 Spring Cloud 的 Eureka 组件，熔断器组件采用了 Hystrix，服务网关使用了 Zuul 和 Spring Cloud Gateway （历史原因），分布式配置主要采用了 Spring Cloud Config （部分小组使用了 Apollo ），并通过 Feign 实现了客户服务端的负载均衡。
但 Spring Cloud 也有一些不可避免的缺点，如基于不同框架的不同组件带来的高应用门槛及学习成本、代码级别对诸多组件进行控制的需求与微服务多语言协作的目标背道而驰。
在我们内部，由于历史原因，不同小组所使用的 API 网关架构不统一，且存在多套 Spring Cloud，给统一管理造成了不便； Spring Cloud 无法实现灰度发布，也给公司业务发布带来了一定不便。更重要的是，作为一家周边游网站，我们经常会举行一些促销活动，面临在业务峰值期资源弹性扩缩容的需求，仅仅依靠 Spring Cloud 也无法实现资源调度来满足业务自动扩缩容的需求。
单纯学习直接katacoda 把
如果真的要起一套完整的，除了 apiserver 和 node 你还得启个 etcd 把，为了高可用，至少三节点起把，或许自定义镜像多了，还得搞个 harbor 呀；再然后整个监控需要收集集群数据，prometheus 不能少吧，顺带搞个报表统计搞个 grafana 对不对；日志没法保存下来分析，整个 ELK 收集日志也需要呀。 所以结论还是直接 katacoda 类似的学习平台入门再考虑攒机器的事情呀～
随着容器化技术的普及，作为 Docker 底层 runtime 的 Containerd 逐步进入人们的视野。
伴随着众多云厂商将其托管服务的底层运行时切换为 Containerd，也从侧面证明了 Containerd 的稳定性。
而近期 Kubernetes 在其最新的 Changelog 中宣布，自 Kubernetes 1.20 之后将弃用 Docker 作为容器运行时，一时间议论纷纷。
Kubernetes is deprecating Docker as a container runtime after v1.20.
pod 是豆荚，里面可以有多颗豆子。
pod 是一组 container，pod 里面的 container 是共享网络栈和存储卷等资源，是一个整体
pod 可以认为是容器组的概念，里面有个 infra container 负责 pod 内所有 container 共享 namespace。
Rancher Labs是业界领先的容器软件提供商，其旗舰产品Rancher是一款开源的企业级Kubernetes管理平台，极为出色地管理和安装Kubernetes集群。他们发布了一系列产品，构成他们的生态，例如，Longhorn是一个轻量级并且可靠的容器化分布式块存储解决方案，可用于Kubernetes中，并在近期被收纳入CNCF沙箱项目中。闲杂让我们回到这篇文章的主题，Rancher Labs也是k3s这款轻量级Kubernetes发行版的创建者。
k3s将安装Kubernetes所需的一切打包进仅有60MB大小的二进制文件中，并且完全实现了Kubernetes API。为了减少运行Kubernetes所需的内存，Rancher删除了很多不必要的驱动程序，并用附加组件对其进行替换。
k3s是一款完全通过CNCF认证的Kubernetes发行版，这意味着你可以编写YAML来对完整版的Kubernetes进行操作，并且它们也将适用于k3s集群。
由于它只需要极低的资源就可以运行，因此它能够在任何512MB RAM以上的设备上运行集群，换言之，我们可以让pod在master和节点上运行。
当人们提到Kubernetes时，他们想到的是如果节点死亡，容器会自动在其他节点上启动，容器之间的负载均衡、隔离和滚动部署，所有这些优点在完整版的Kubernetes和k3s之间是相同的。
但是，k3s并不总是只有优点，否则的话每个人都会去使用k3s。那么，为什么有些人没有使用k3s呢？
首先，当前k3s的版本（k3s v0.8.1）仅能运行单个master，这意味着如果你的master宕机，那么你就无法管理你的集群，即便已有集群要继续运行。但是在k3s v0.10的版本中，多主模式已经是实验功能，也许在下一个版本中能够GA。
其次，在单个master的k3s中，默认的数据存储是SQLite，这对于小型数据库十分友好，但是如果遭受重击，那么SQLite将成为主要痛点。但是，Kubernetes控制平面中发生的更改更多是与频繁更新部署、调度Pod等有关，因此对于小型开发/测试集群而言，数据库不会造成太大负载。
docker(现在名为 moby)技术分三类：镜像以及仓库、运行时（ runc，原名 libcontainerd ）、docker engine 守护进程；容器编排技术是 swarm。
其中，runc 贡献给了云原生基金会；镜像以及仓库普及度就不用说了； docker engine 用于单机，价值不大。
没有编排技术的容器，是个玩具。然而，swarm 在编排竞争中落败，k8s 成为事实上的标准。
docker 式微，指的是，docker 公司在编排技术中竞争失败，加之容器被标准化，存在感不强了，更重要的是，没有盈利手段（收入大头 docker enterprise 被打包卖给了别的公司）。
手动部署(利于学习整个部署流程)： https://github.com/opsnull/follow-me-install-kubernetes-cluster https://github.com/kelseyhightower/kubernetes-the-hard-way
minikube 部署 Minikube 是一个工具，可以在本地快速运行一个单点的 Kubernetes，尝试 Kubernetes 或日常开发的用户使用。但是这种方式仅可用于学习和测试部署，不能用于生产环境。
kubeadm kubeadm 是一个 kubernetes 官方提供的快速安装和初始化拥有最佳实践（ best practice ）的容器化 kubernetes 集群的工具，提供 kubeadm init 和 kubeadm join，用于快速部署 Kubernetes 集群
kubeasz 国人项目，kubeasz 使用 ansible 快速部署非容器化 高可用 k8s 集群，国内友好，所需二进制文件都是从 docker.io 镜像中 copy 的，免去 quay.io gcr.io 等仓库下载不便
kubespray 官方出品部署工具。kubespray 使用 ansible 基于 kubeadm 快速部署容器化 高可用 k8s 集群，默认从 quay.io gcr.io 等官方地址下载镜像，国内不太友好，不过也可以调整参数指向国内镜像
个人推荐使用 后两种
正在按照
1 、k8s 权威指南
2 、极客时间张磊有个专栏叫 《深入剖析 Kubernetes 》
3 、最重要的自己动手实践
强力推荐张磊的专栏，写的很好
- 单机都是直接 docker-compose 超级方便
- Github Registry 了解一下，可以私有项目传镜像哦
我一开始觉得入门也很难，摸索了很久，现在倒是可以分享一下如何入门。
1、抛弃 UI，不管是 GUI 还是 WebUI，也不要把部署一个 dashboard 当作目的，不要管 UI，一心 cli。
2、只看《 kubernetes in action 》这本书，有中文版
3、最好使用完整的 kubernetes 环境来练手，可以使用 kubeadm 架设或者直接使用 kubeasz 脚本架设，一开始不必考虑原理，等以后再完整二进制部署
4、给自己设定一个时间，比如 2 天泛读完这本书，1 周实践完这本书
- 调整预期。非集群的 docker 及 docker-compose 的复杂度和 Kubernetes 不是一个级别，所以学习难度的预期不应该一样。
- 模拟环境。建议 kubeadm 搭建双节点来学习，不建议入门使用其他的发行版或工具，如 rancher、openshift 等。就入门学习来说，这些工具对原生 Kubernetes 进行了封装，一方面阻碍了对原生概念的理解，另一方面引入了封装后的概念，增加了学习量。一个不太恰当的比喻，我们更倾向于学习 Linux 本身而不是某个具体的发行版。这个比喻不太恰当是因为我们很难绕过具体的发行版去学习 Linux，但 Kubernetes 却不是。入门之后再去了解各种*KE、*KS 会更容易些。
- 手动练习。不要依赖图形化的 UI，就使用 kubectl，手写各种资源的 yaml，把各种资源都调试部署一遍。yaml 中的常用字段对着手册理解。有了基本理解后，推荐找一些好的 yaml 参考学习。这里推荐 helm 仓库，不是说要用 helm 部署，而是用 helm template 来导出各种部署的 yaml 来学习，看看仓库里的 yaml 都是怎么写的，为什么这么写。个人感觉对学习很有帮助。
资料建议以官方文档和手册为主，弄懂各种概念是实践的前提。
上了 k8s，就不要用 Spring Cloud 那一套笨重的东西了，k8s 生态里都有链路追踪和远程调用的替代方案。至于微服务也应该贴合具体业务上下文的关系来，如果每个业务都拆开，维护成本提升会大于利处，徒增消耗。
我们技术团队目前 20 人，外包团队加起来有 80 人左右，目前就是 SpringCloud+K8s 这一套。目前是我在主推，前期是需要花点时间来做一些基础的工作，但是对于后期来说节省了太多的时间成本，没有用过就没有发言权，那些劝你别上的，估计自己也没用过，而且上 k8s 对于开发人员来说是无感知的，至于 Springcloud 我们用了三年了，你会了 Springboot，业务大了自然后拆分，看你业务的复杂性，我们单体和 SpringCloud 都有，具体业务选择不同的架构，只要做大，上微服务是必须的，就看你们现有业务体量了
k8 成本很高的. 人家给你的复杂方案,等你折腾半年弄懂了, 最后会发现有价值的就是服务里那几十行 php 代码.
同意楼上的. 也就刷刷简历有作用. 实际用起来. 大半时间在维护上. 成本巨高
我们后端开发不到 10 人, 架构经历是 tomcat+war => spring boot => spring boot + docker => spring boot + 阿里 k8s => spring cloud + nacos + 阿里 k8s , 以上历时一年半
没必要着急上 k8s，但是容器化可以先做，12 factor 可以先搞起来（ https://12factor.net/zh_cn/ ），有这个基础之后，后续想迁移也容易了。
Docker Swarm 赶紧扔掉。我也是后端，最近也在搞运维等基础设施，swarm 彻底死了。
一個人搞的 K8s 都比十個人維護 Swarm 強，勸退+1
可以理解基于 k8s 的模块是一套 paas (Platform As A Service) 平台，基于 springcloud 微服务的模块是 saas (Software As A Service) 平台(当然我们也基于 istio 构建了一套 service mesh 模块，那个才是真正的 sass 平台）。如果从开发角度，专注实现 saas 平台的基本功能就可以了，往后团队大了，面临的问题还有日志采集，服务监控，链路追踪，网关路由，容器网络管理，底层计算资源维护等等等等。
Spring Cloud==> Microservice 1.0 国内开发人员依赖 Spring 太厉害了。
K8s ===> Microservice 2.0 现在容器编排几乎是 K8s 一家独大。
以前一个海外项目 ，Spring Cloud 开始有雏形（主要是集成 Netflix 那一套）的时候就开始试用（当然我们会写 POC 进行比较），结果我们放弃了几乎所有的 Spring Cloud 项目（除了日志跟踪），当时我们认为最大的问题，它将运维的一些东西全部集成到代码，性能上成问题，而且后期运维，扩展非常不方便。像 Service Discovery，Config，Load Balance，Circuit Breaker 这些可以说用容器方便的得多， 将这些打包进 Service，本身就违背 Microservice 的初忠。每个 Service 本身就是应该集成在解决业务问题， 对于用什么技术并不重要。
dubbo 类似于 Spring Cloud 的一个子集，springcloud 是一整套的微服务治理解决方案
微服务 1.0：仅使用注册发现，基于 Spring Cloud 或者 Dubbo 进行开发。
微服务 2.0：使用了熔断、限流、降级等服务治理策略，并配备完整服务工具和平台。
微服务 3.0：Service Mesh 将服务治理作为通用组件，下沉到平台层实现，应用层仅仅关注业务逻辑，平台层可以根据业务监控自动调度和参数调整，实现 AIOps 和智能调度。
到目前为止，根本不存在通用型的 Service Mesh，否则这东西早就风靡起来了，就是在大厂，他们的 Service Mesh 也是和他们的业务高度耦合的；只能在他们的应用场景下，实现“自动调度和参数调整”。换一个场景，就要傻眼和重新调整。
我非常理解后端开发的痛点以及一直以来都希望有一套系统能屏蔽掉大型系统的治理难题。让应用层真的“仅仅关注业务逻辑”。然而现实是，没有谁真正通用的做到这一点了。只能在有限的场景下近似的完成。
微服务实施中 DevOps 是一等公民，如果在 Infrastructure 上不能做到自动化，不写测试，不做 CI、CD，还是算了吧。这个我了解过国内所谓在实施微服务的，基本很少去做，靠人肉运维还是算了吧，你永远不是微服务。
微服务为容器而生，Spring Cloud 最大问题就是把微服务一些运维相关的东西耦合到应用之一，会导致写测试非常不方便。在 Spring Cloud 刚出来的时候，那时只有 Netflix 那一套，一个项目 Dropwizard 迁移过来，做了大量的 POC，最终我们只采用了 Spring Cloud 的日志跟踪，其他全部用容器（ Service Discovery, Load Balance 等）实现。
实现案例 #
沒有銀彈.
微服務肯定要付出代價.
原本單體用 ORM 從 DB 讀出來, 變成 Object 在內存操作處理多快. 微服務要物件序列化在網路間傳來傳去, 可以多付點雲服務商流量費.
- 约 329 个 Go 服务, 历史约 170 人左右贡献过 Go 代码. 其中 admin 目录下 54 个, infra 目录下 5 个基础组件服务, interface 下 77 个, job 目录下 80 个, service 目录下 113 个.
- 代码和目录规范性比较好, 代码生成工具建设比较好, 大家可以借鉴一下.
- 对于一个 Golang 开发者来说, 入职 B 站, 我觉得大概 2-3 天就可以 copy&&paste 开始贡献业务代码了. 其他语言开发者, 3-4 天吧, 因为学习 Golang 花一天.
- B 站 Go 不依赖 CGO, 业务代码可以在 windows 编译通过! 启动!
- 组件基本是基于开源组件封装.
- RPC 基于 grpc 封装, 协议编码为 proto, 没有我们通常那样的包头.
- 服务注册与发现已经包装在 RPC 中. 注册使用自研的 discovery, 基于类似 url 的方式去注册和寻址.
- 数据存储多使用 memcache, redis 和 DB.
- hbase 也使用比较多. 用于鉴权, 用户数据存储. 对于一些 kv 数据, 外部没有支持冷热分离的 kv 存储, hbase 是一个非常好的选择: 基于 HDFS, 热数据加载到内存, 列式存储, 强一致, 可配置副本数.
- 消息队列为使用基于 kakfa, 实现了 redis 协议的 databus.
- 小文件存储: B 站自己实现的 bfs
- 监控上报使用的是 prometheus, 对于中小公司, 没法建设自己的监控组件, prometheus 是很不错的选择.
- 简单浏览了下, 这份代码在 SQL 上没有注入风险. 生产环境的配置并没有在这份代码中. 一个合格的开发者, 即使所有源码流出去, 也不会对系统造成任何危害.
我搞这些东西搞了很多年. 我的建议是小重复无所谓, 大重复要重新审视服务划分. 大重复又改不动划分的话可以用 monorepo 凑合, 无论如何业务代码不要用包的形式复用.
最理想的方式:
正确分割上下文(其实就是所谓战略设计), 每个微服务之间尽量不要有重叠. 一旦划分错了重叠就会多, 后面选哪条路都有问题, 是无解的.
几种实践中的方式:
重复比较少的时候忍一忍, 抄代码有重复是没事的.
重复多的时候要想的第一件事是分割有错, 应该先考虑能不能把服务合并回去.
重复多的时候抽公共服务, 但是公共服务的问题是会分层, 公共服务之间也会有公共服务, 最后变成金字塔, 服务数量指数级爆炸, 而且经常需要调整重构, 需要公用的地方会越来越多(因为服务变太小了), 对服务的单元测试质量也会下降(业务覆盖率太低). 所以公共服务非到万不得已不抽. 抽出来的都是业务很稳定的“中台”. 对于中台我的建议也是没有必要不搞.
不推荐的方式:
- 包管理, 如果跟业务完全没有关系可以用包. 跟业务沾边就绝对不要用. 如果想公用, 又没有足够的人力像上述第 2 条那样合并服务, 可以简单把代码库合成一个 monorepo, 但是还部署成多个服务, 这样的好处是没有版本问题.
为什么不建议用包? 因为假设两个组的服务 A 和 B 都用了包 X, A 用的比较频繁, A 升级 X 比较频繁, B 升级不频繁, A 一年升级了 50 个版本. 某题 B 想升级 X, 发现 X 已经被修改了很多次, 要升级就要把之前的 API 全升级成 X 的最新版, 但是 B 在这一年里完全是基于旧的 X 写的新代码, 如果想升级则不得不把这年跟 X 相关的代码全部重写.
时空乱流记录