本次技术分享只做技术宏观思维与认知上的分享，具体配置细节与部署不在此次讨论范围。 讨论点： 1、微服务的局限性 2、了解 Server-Mesh 功能与实现方式 3、目前基于 Server-Mesh 而实现的 Serverless 我们最熟悉，最常用的 Java，Spring-Cloud，Spring-Cloud-Alibaba 等技术体系，归属于传统微服务的架构设计，此设计存在SDK强耦合问题，每次底层SDK版本的更新极大可能影响到业务层面的服务稳定性。SDK与代码环境强耦合，就会存在居多限制，不能完整的运用市面上不同语言与其对应的生态组件来做更擅长的领域，例如：灵活快速的Go，Python语言并对应其携程，爬虫，神经网络等等组件。严谨并且0垃圾回收的Rust语言，更适合企业级中间件高效率低内存占用场景。所以每种语言有它各自的优势与生态环境，以更长远的发展来看，大体量的龙头企业将会把业务部署与实现落地到不同的语言上进行迭代是一种趋势。 传统微服务体系图： 并且如今JVM引以为傲的跨操作系统优势，其特性也被K8S，Docker，Containerd，CRI-O，Kata

通过在k8s集群中部署Istio作为Service Mesh架构，利用它本身的Envoy代理转发流量的特性，轻松的支持了流量镜像的功能，只需要在配置文件中简单加上几个配置即可完成流量镜像，此功能非常强大，如用得当可以更好的服务生产环境的业务需求。流量镜像也被称作影子流量，把客户端打入的请求进行复制并转发到其他容器进行处理，但镜像的流量不会响应数据给客户端，如此一来流量镜像的价值就变得非常清晰，我们可以用流量镜像做数据记录，风控分析，线上异常操作跟踪，并且对于原来的业务代码是完全透明的，毕竟在流量进入容器前已经进行了流量的镜像，并通过部署其他容器服务进行处理。极大的增强了业务的横向扩展能力。 镜像此任务演示了 Istio 的流量镜像/影子功能。Istio阅读大约需要 3 分钟 页面测试 针对流量镜像的典型的使用场景： 1、测试环境：测试版本的容器服务可以使用生产实例的真实流量，不会影响正常生产的关键路径。例如预发布环境就可以更好的进行实时测试校验，减少发布后出现的各种异常情况，给开发团队更好的上线信心 😂，上线几乎可以做到清晰明了，不用熬夜加班发版。 2、数据采集：同步收集请求

众所周知，k8s可以在多个node节点上管理容器资源，但每个容器需要对应的pod-yaml文件来进行管理。 我们先说问题：如果在一个namespace中有几十个pod需要进行配合部署，例如 mysql 集群，kafka集群，但部署kafka集群又需要先部署 zookeeper集群，应用程序又需要Redis 集群，以及一些MQ队列集群，还有应用程序自身的部署，微服务可能多达50-100个甚至更多的应用。 这样的场景让你来写 yaml 配置文件 我想你可能是拒绝的，就算你部署了一次，好不容易部署完成了，但异地机房集群还要再次部署怎么办? 更何况怎么做到多个不同机房中集群的配置信息完全一致？ 所以这里的问题很明显了，我们需要一个可以集中管理所有 yaml 配置文件并且可以复用的工具。 于是 Helm 就诞生了，他的定位类似于 CentOS 中的 Yum 包管理工具，又或者是 Debian中的 apt 包管理工具，只不过这次的包管理是基于 k8s 环境。 Heml 中的每个包都称为一个Chart，一个Chart是一个目录。 应用发布者可以通过Helm打包应用，管理应用依赖关系，管理

此文件相关配置查询(此文件只做参考,以查询为准) kubectl explain 为文档查询命令如：kubectl explain pod.spec.volumes apiVersion: v1 //版本 kind: pod //类型，pod metadata: //元数据 name: String //元数据，pod的名字 namespace: String //元数据，pod的命名空间 labels: //元数据，标签列表 - name: String //元数据，标签的名字 annotations: //元数据,自定义注解列表 - name: String //元数据,自定义注解名字 spec: //pod中容器的详细定义 containers: //pod中的容器列表，可以有多个

kubectl --help ：帮助信息 kubectl delete Deployments -n <命名空间> kubectl get nodes ：查看集群节点数 kubectl get pod -n <命名空间> ：查看对应命名空间下pod信息 kubectl get pods -A 查看所有pod kubectl get namespace ：查看命名空间 kubectl get pod --all-namespace 查看所有命名下的pod kubectl apply -f ：应用pod配置文件，设置资源 kubectl delete -f ：取消应用pod配置文件，删除资源 kubectl create 通过yaml/json 文件或者标准输入创建一个资源对象 kubectl drain