无论是debian还是redhat，亦或者其他linux发行版，都有一个包管理用来解决依赖问题，而在kubernetes中，helm是用来管理kubernetes应用程序，其中charts是可以定义一个可以进行安装升级的应用程序，同时也容易创建起来，并且进行版本管理。而在越复杂的应用程序来讲，hel
2023-07-15
ingress-nginx basic auth认证是最简单和基础的，要使用它，需要安装httpd，提供一个htpasswd，而后使用htpasswd -c auth NAME 的方式创建一个文件，而后是以哦那个create来创建，如下kubectl create secret generic ba
2023-07-15
helm说白了其实就是一个模板渲染系统，核心就在templates和values，模板使用了go template编写的，并且增加了sprig库，共计50个左右的附加模板函数和其他的一些函数。如果要进行使用，必然要遵循template的模板的约定)，比如{{ if pipeline }} T1 {{
2023-07-15
通常，无状态的应用多数情况下以deployment控制器下运行，在deployment更新中，当配置清单发生变化后，应用这些新的配置。我们假设一些都ok，也成功拉取镜像，并且以默认的25%进行滚动更新，直到更新完成。kubectl apply -f test1.yaml然而这一切按照预期进行，没有任
2023-07-15
在开发一个chart的时候就需要对整个模板进行了解，从使用角度来说，是简单的。但是去开发的时候就需要一定的认识才能够完成一个模板的开发。而在其中用的较多的就是内置的一些函数，或者说是对象，通常，在helm的模板变量中，以大写开头的都是系统提供的，这由Go的函数约定。内置对象releasereleas
2023-07-15
8.9.0是skywalking发布的最后一个功能版本，从2018年开始，skywalking一直是在服务，端点，实例间依赖的关系和拓扑结构，基于代理跟踪监控发展到全栈，包括日志，跟踪，指标和事件等。也添加了更多，如vm，k8s监控，服务网格。同时也引入了更多的方式来观测，如：ebpf但是在8.x的
2023-07-15
在helm中除了此前的那些内置函数和定义的一些valumes的值替换，这些对象和控制语句，还有一些管道之外，仍然提供了变量。大多数编程语言中，都有变量。如，在golang中以及groovy中都提到了全局变量和局部变量。 他们的作用域范围不同全局变量全局变量，顾名思义，所有都可以使用局部变量在某一块的
2023-07-15
如下图所示我们先查看下pod的调度情况，分别是10.11.1.45和10.11.0.10在不同的两个节点，并且是不同的网段不同的网段，那么久需要查找路由表，看路由信息[root@master1 ~]# kubectl get pod -o wide NAME
2023-07-15
kustomize一直是备受欢迎的yaml配置管理之一，在过去kustomize一直在解决 “提供一种操作配置数据的方法，而不会使原始配置无法被 Kubernetes 使用。”，我们不用去和其他工具做比较，因为这就是kustomize的魅力所在。但是kustomize也有自己的缺点，它无法像helm
2023-07-15
在早先，容器仓库有Portus和harbor最为瞩目，harbor是vmware的产品，而前者则是由suse团队维护，但在2019portus提供了最后一个版本。但随着时间的推移，harbor提供了更多与时俱进的功能服务，这也导致harbor愈发的收到关注和使用。并且harbor是由vmware中国
2023-07-15
我们知道，当应用程度到达了一定程度大的时候，必然会走到分布式，而微服务是作为分布式的一种极致表现。谈到微服务，不得不去提微服务治理，在这之前，我们了解下分布式架构治理模式的演进。服务治理在早期的治理能是是嵌入在业务代码中的，典型技术如：SOA,ESB，开发人员把服务治理的代码写入到程序中来实现服务发
2023-07-15
要想部署istio，我门需要kubernetes组件。控制平面默认部署在istio-system名称空间内，包含，istiod,ingress-gateway,egress-gateway,addons(kiali.prometheus,grafanajacger)。而数据平面的自动注入只会在部署应
2023-07-15
网格中有很多service，sidecar就会看到很多egerss listeners通过正向代理来确保pod访问之外服务的时候是通过sidecar来代理，ingress是来接受外部访问内部的，但这并不多，该pod被后端端点的service 的端口所属的服务会在该pod的sidecar生成ingre
2023-07-15
4.kiali配置ingress和egress分别处理的出和入的流量，而大部分相关资源都需要定义资源来完成。每个pod访问外部的时候，流量到达sedcar上，而sedcar上有对应的配置。这些配置包括：集群内有多少个服务服务对应的pod是什么访问给服务流量的比例是多少而virtualServIce就
2023-07-15
流量治理在istio1.5后的版本，istiod充当控制平面，并且将配置分发到所有的sidecar代理和网关，能够支持网格的应用实现只能话的负载均衡机制。而envoy通过简单的二次开发后在istio中称为istio-proxy，被用于围绕某个pod，以sidecar的模式允许在某个应用的pod中。除
2023-07-15
定义subset子集我们将两个版本归类到一个版本的pod上，去进行适配到一个pod上去，通过标签关联来做区分对于多个版本，在同一个host,通过标签来标注不同的版本信息来进行管理，而后在vs中进行调用子集需要在DestinationRule集群上面进行配置DestinationRule在cluste
2023-07-15
3.开放到外网我们通过域名通过外网来访问集群内的这两个pod，就需定义gateway和vs，vs也是定义在网关gateway打开侦听器gateway必须在网格部署的所在名称空间内，否则有可能注入失败VirtualService定义路由信息等此前定义的VirtualService并没有指定网关，如果没
2023-07-15
紧接前面，这篇我们希望访问dpment服务的请求在百分之90的流量在原来的v10的pod，而百分之10的在新的v11的pod，因此我们配置weight来实现基于权重比例的流量切割首先部署dpment-a和dpment-b仍然需要配置service关联到后端的pod标签apiVersion: v1 k
2023-07-15
5.请求首部条件路由正常情况下从客户端请求的流量会发送到sidecar-proxy(eneoy)，请求发送到上游的pod，而后响应到envoy，并从envoy响应给客户端。在这个过程中，客户端到envoy是不能够被修改的，只有从envoy到上游serrvice中才是可以被操作的，因为这段报文是由en
2023-07-15
6.故障注入istiO支持两种故障注入，分别是延迟故障和中断故障延迟故障：超时，重新发送请求abort中断故障：重试故障注入仍然在http层进行定义中断故障 fault: abort: # 中断故障 percentage: value: 20
2023-07-15