通常，无状态的应用多数情况下以deployment控制器下运行，在deployment更新中，当配置清单发生变化后，应用这些新的配置。 我们假设一些都ok，也成功拉取镜像，并且以默认的25%进行滚动更新，直到更新完成。 kubectl apply -f test1.yaml 然而这一切按照预期进行，没有任何问题。 kubectl只是将配置推送到k8s后，只要配置清单没有语法或者冲突问题，返回的是0

在开发一个chart的时候就需要对整个模板进行了解，从使用角度来说，是简单的。但是去开发的时候就需要一定的认识才能够完成一个模板的开发。 而在其中用的较多的就是内置的一些函数，或者说是对象，通常，在helm的模板变量中，以大写开头的都是系统提供的，这由Go的函数约定。 内置对象 release release：release是作为顶级对象的，与下面的其他不同的是她是内置函数。字面上release是

8.9.0是skywalking发布的最后一个功能版本，从2018年开始，skywalking一直是在服务，端点，实例间依赖的关系和拓扑结构，基于代理跟踪监控发展到全栈，包括日志，跟踪，指标和事件等。也添加了更多，如vm，k8s监控，服务网格。同时也引入了更多的方式来观测，如：ebpf 但是在8.x的版本中使用了组的概念来解决混合的问题，但在v9核心中最重要的概念是LAYER 层代表计算机科学中的

在helm中除了此前的那些内置函数和定义的一些valumes的值替换，这些对象和控制语句，还有一些管道之外，仍然提供了变量。 大多数编程语言中，都有变量。如，在golang中以及groovy中都提到了全局变量和局部变量。 他们的作用域范围不同 全局变量 全局变量，顾名思义，所有都可以使用 局部变量 在某一块的代码内被使用，而代码块作用域外无法使用 有了这些的支撑，更好理解变量的出现以及使用的问题

如下图所示 我们先查看下pod的调度情况，分别是10.11.1.45和10.11.0.10在不同的两个节点，并且是不同的网段 不同的网段，那么久需要查找路由表，看路由信息 [root@master1 ~]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE marksugar-deployment-578cdd567b-9

kustomize一直是备受欢迎的yaml配置管理之一，在过去kustomize一直在解决 “提供一种操作配置数据的方法，而不会使原始配置无法被 Kubernetes 使用。”，我们不用去和其他工具做比较，因为这就是kustomize的魅力所在。 但是kustomize也有自己的缺点，它无法像helm那样灵活多变，比如，在配置多个一个Ingress的域名的时候，这在helm中将会非常简单，但是在k

在早先，容器仓库有Portus和harbor最为瞩目，harbor是vmware的产品，而前者则是由suse团队维护，但在2019portus提供了最后一个版本。但随着时间的推移，harbor提供了更多与时俱进的功能服务，这也导致harbor愈发的收到关注和使用。并且harbor是由vmware中国区成员参与，众所周知，一款提供中文界面且有优秀的产品，往往都是更受欢迎的。 harbor不仅可以存放

我们知道，当应用程度到达了一定程度大的时候，必然会走到分布式，而微服务是作为分布式的一种极致表现。谈到微服务，不得不去提微服务治理，在这之前，我们了解下分布式架构治理模式的演进。 服务治理在早期的治理能是是嵌入在业务代码中的，典型技术如：SOA,ESB，开发人员把服务治理的代码写入到程序中来实现服务发现，符在均衡，熔断容错，动态路由。这意味着每个开发人员都需要在自己的模块内维护一个这些功能。 而到

要想部署istio，我门需要kubernetes组件。控制平面默认部署在istio-system名称空间内，包含，istiod,ingress-gateway,egress-gateway,addons(kiali.prometheus,grafanajacger)。而数据平面的自动注入只会在部署应用之后部署在应用的名称空间内，以Sidecar 运行，并且是需要打上一个label才能被启用。 而e

网格中有很多service，sidecar就会看到很多egerss listeners通过正向代理来确保pod访问之外服务的时候是通过sidecar来代理，ingress是来接受外部访问内部的，但这并不多，该pod被后端端点的service 的端口所属的服务会在该pod的sidecar生成ingress listeners，通过ingress反向代理完成访问 如： istio-system和被打上

4.kiali配置 ingress和egress分别处理的出和入的流量，而大部分相关资源都需要定义资源来完成。 每个pod访问外部的时候，流量到达sedcar上，而sedcar上有对应的配置。这些配置包括： 集群内有多少个服务 服务对应的pod是什么 访问给服务流量的比例是多少 而virtualServIce就是为了这些来定义，这类似于nginx的虚拟主机。virtualServIce为每一个服务

流量治理 在istio1.5后的版本，istiod充当控制平面，并且将配置分发到所有的sidecar代理和网关，能够支持网格的应用实现只能话的负载均衡机制。 而envoy通过简单的二次开发后在istio中称为istio-proxy，被用于围绕某个pod，以sidecar的模式允许在某个应用的pod中。除此之外envoy还负责ingress和egress，分别是入向和出向网关。 在k8s中，一旦is

定义subset子集 我们将两个版本归类到一个版本的pod上，去进行适配到一个pod上去，通过标签关联来做区分 对于多个版本，在同一个host,通过标签来标注不同的版本信息来进行管理，而后在vs中进行调用 子集 需要在DestinationRule集群上面进行配置 DestinationRule在cluster配置的，通过routes进行调度 基于子集，在本案例中根据version标签来备注，类似

3.开放到外网 我们通过域名通过外网来访问集群内的这两个pod，就需定义gateway和vs，vs也是定义在网关 gateway打开侦听器 gateway必须在网格部署的所在名称空间内，否则有可能注入失败 VirtualService定义路由信息等 此前定义的VirtualService并没有指定网关，如果没有指定，就只会在网格内的各sidecar内使用 如果只是这样，那么网格内部是不能访问的，如

紧接前面，这篇我们希望访问dpment服务的请求在百分之90的流量在原来的v10的pod，而百分之10的在新的v11的pod，因此我们配置weight来实现基于权重比例的流量切割 首先部署dpment-a和dpment-b 仍然需要配置service关联到后端的pod标签 apiVersion: v1 kind: Service metadata: name: dpment namespace:

5.请求首部条件路由 正常情况下从客户端请求的流量会发送到sidecar-proxy(eneoy)，请求发送到上游的pod，而后响应到envoy，并从envoy响应给客户端。 在这个过程中，客户端到envoy是不能够被修改的，只有从envoy到上游serrvice中才是可以被操作的，因为这段报文是由envoy发起的。而从serrvice响应到envoy的也是不能够被修改的。并且从envoy响应到客

6.故障注入 istiO支持两种故障注入，分别是延迟故障和中断故障 延迟故障：超时，重新发送请求 abort中断故障：重试 故障注入仍然在http层进行定义 中断故障 fault: abort: # 中断故障 percentage: value: 20 # 在多大的比例流量上注入 httpStatus: 567 # 故障响应码 延迟故障 fault: delay: percentage: valu

bookinfo 其中包包中有一个 bookinfo的示例，这个应用模仿在线书店的一个分类，显示一本书的信息。 页面上会显示一本书的描述，书籍的细节（ISBN、页数等），以及关于这本书的一些评论。 Bookinfo 应用分为四个单独的微服务： productpage. 这个微服务会调用 details 和 reviews 两个微服务，用来生成页面。 details. 这个微服务中包含了书籍的信息。

robusta的功能远不止本章介绍的这些，它可以去监控Kubernetes，提供观测性，可以于prometheus接入，作为告警的二次处理，自动修复等，也提供了事件的时间线。 此前使用的是阿里的kube-eventer，kube-eventer仅仅只是提供了一个转发，因此kube-eventer只能解决的是事件触发的通知。 当然， 如果robusta也是仅仅止步于此，那也没用多少必要性去使用它。它

在编译安装时请注意需求！必要时查看官方文档！ [root@centos3 ~]# rpm -qi glibc Name : glibc Relocations: (not relocatable) Version : 2.12 Vendor: CentOS Release : 1.149.el6 Build Date: Wed 15 Oct 2014 10:00:58 AM CST Install