sidecar

用spring cloud sidecar的整合异构语言，以前做过没有做笔记，现在再做由于各种坑又浪费了一天，这里记一下 首先是官网：http://cloud.spring.io/spring-cloud-static/spring-cloud-netflix/1.3.1.RELEASE/ 官网上面讲sidecar讲的很简单，具体怎么做这里就不记了，无非就是加包，然后在主函数上面注解，再在配置文件里面写点东西，以后再看官网就行了，这里记一下官网没有讲到的东西 1.sidecar是用来整合异构语言的，比如你用python，nodejs等等写的东西，sidecar这个服务必须和python或nodejs等异构语言的服务在同一台主机上面，也就是说他们之间是localhost，不能是ip访问等等 2.sidecar检查异构语言的健康地址返回结果是： { "status":"UP" } 这里需要注意，这个json结果不是是我们直接写出来的，好几次我都是为了方便直接在return里面写的数据，如果这样启动sidecar的时候，你会发现注册中心sidecar一直是down，那是因为你的response header没有改过来，所以我们可以把数据发到map里面，如何用json包转化成json数据，其他的方式也是可以的。其实原理是response header里面解析的text/html

作者简介 Pankaj Gupta，就职于Citrix，是云原生应用程序交付解决方案的高级总监。 近两年微服务架构十分流行，许多公司也正在努力构建自己的微服务架构。而因为微服务能够实现更快的发布周期、将应用程序模块化、弹性伸缩以及让应用程序具备可移植性，其越来越成为企业数字化进程中不可忽视的标志。但是，由于对敏捷性所产生的影响了解较少，使得应用程序交付增加了许多复杂性。 对于此，有什么解决方案呢？ 选择合适的代理架构和应用程序交付controller（ADCs）对最终用户获得最佳体验至关重要。它必须能够提供合适的安全等级、观察性、高级流量管理以及故障排查能力并且能够兼容你的开源工具。此外，代理架构必须能够同时满足南北流量和微服务间东西流量的需求。 单体应用程序的负载均衡十分简单。但是对于基于微服务的应用程序而言，负载均衡则更为复杂。 本文将介绍4个代理架构，并根据基于微服务应用程序交付的7个关键标准对其中几个进行评估。 在优势和复杂性之间进行权衡 首先，我们需要达成共识：微服务架构实际上是十分复杂的。在开源创新的推动下，最佳实践随着技术的进步而迅速发展。不同的架构拥有不同的优势，但是也呈现出不同程度的复杂性。很多时候，我们需要在自己实际所需的好处（例如安全性、可观察性）和复杂性之间做出取舍。尤其当你考虑实施特定架构所需的技能和为了满足大众需求而必须添加的功能时

作者简介 Pankaj Gupta，就职于Citrix，是云原生应用程序交付解决方案的高级总监。 近两年微服务架构十分流行，许多公司也正在努力构建自己的微服务架构。而因为微服务能够实现更快的发布周期、将应用程序模块化、弹性伸缩以及让应用程序具备可移植性，其越来越成为企业数字化进程中不可忽视的标志。但是，由于对敏捷性所产生的影响了解较少，使得应用程序交付增加了许多复杂性。 对于此，有什么解决方案呢？ 选择合适的代理架构和应用程序交付controller（ADCs）对最终用户获得最佳体验至关重要。它必须能够提供合适的安全等级、观察性、高级流量管理以及故障排查能力并且能够兼容你的开源工具。此外，代理架构必须能够同时满足南北流量和微服务间东西流量的需求。 单体应用程序的负载均衡十分简单。但是对于基于微服务的应用程序而言，负载均衡则更为复杂。 本文将介绍4个代理架构，并根据基于微服务应用程序交付的7个关键标准对其中几个进行评估。 在优势和复杂性之间进行权衡 首先，我们需要达成共识：微服务架构实际上是十分复杂的。在开源创新的推动下，最佳实践随着技术的进步而迅速发展。不同的架构拥有不同的优势，但是也呈现出不同程度的复杂性。很多时候，我们需要在自己实际所需的好处（例如安全性、可观察性）和复杂性之间做出取舍。尤其当你考虑实施特定架构所需的技能和为了满足大众需求而必须添加的功能时

1 性能增强 虽然Istio1.0的目标是生产可用，但从去年7月份发布以来，在性能和稳定性上并不能让用户满意。社区的Performance and Scalability工作组在Istio v1.1中做了大量的努力以提高控制面和数据面的性能，其中最明显的性能增强包括： Sidecar API，减少发给proxy的配置数量以及pilot负载。 网络配置规则（Destinationrule,Virtualservie, ServiceEntry）中增加的 exportTo字段限制配置的可见范围。 Envoy默认收集的统计数据大量减少。 给mixer增加load-shedding功能，防止overload。 提升envoy和mixer之间的交互协议。 可配置并发线程数，提高吞吐量。 可配置filter来约束mixer遥测数据。 从对Istio 1.1的测试数据来看，这部分工作取得了显著的效果。 1.1控制面性能表现 Pilot的CPU和内存使用受网格内的配置和系统状态的影响，例如负载变化速率，配置变化速率，连接到Pilot的proxy的数量等。可以通过增加Pilot的实例数来减少配置分发处理的时间，提高性能。 在网格内有1000个服务，2000 个sidecars，每秒1000请求下的表现： 单Pilot 实例使用 1 vCPU 和1.5 GB 的内存。 istio

一、自动注入的前提条件 自动注入功能需要kubernetes 1.9或更高版本； kubernetes环境需支持MutatingAdmissionWebhook； 二、在namespace中设置自动注入，这样所有在该namespace的创建的pod都会自动注入sidecar代理 以default命名空间为例： kubectl label namespace default istio-injection=enabled 在default里面创建一个deployment apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-app spec: replicas: 1 template: metadata: annotations: sidecar.istio.io/inject: "true" labels: app: nginx-app spec: containers: - name: nginx-app image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80 [root@master test-yaml]# kubectl get po NAME READY STATUS RESTARTS AGE nfs

上文主要讲解了如何部署istio，有一项是 自动注入sidecar ，本文主要解析一下sidecar的自动注入源码 原理：istio通过kubernetes的 MutatingAdmissionWebhook 来实现自动注入，当启用了该准入控制器以后，会在 符合配置条件的namespace 下的 pod创建之前 访问对应的服务来将sidecar注入进去，接着继续部署pod。 先来解释一下istio官方给出的MutatingAdmissionWebhook配置的yaml文件： 1 apiVersion: admissionregistration.k8s.io/v1beta1 2 kind: MutatingWebhookConfiguration 3 metadata: 4 labels: 5 app: sidecarInjectorWebhook 6 chart: sidecarInjectorWebhook 7 heritage: Tiller 8 release: istio 9 name: istio-sidecar-injector 10 webhooks: 11 - clientConfig: 12 caBundle:

目录 istio sidecar自动注入过程分析 sidecar自动注入检查 检查kube-apiserver 检查sidecar-injector的configmap 检查namespace标签 sidecar自动注入过程 webhook过程 proxy_init proxyv2 istio sidecar自动注入过程分析 istio通过 mutating webhook admission controller 机制实现sidecar的自动注入.istio sidecard在每个服务创建pod时都会被自动注入. sidecar自动注入检查 检查kube-apiserver webhook支持需要Kubernets1.9或者更高的版本,使用以下命令查看 [root@test1 ~]# kubectl api-versions | grep admissionregistration admissionregistration.k8s.io/v1beta1 同时检查kube-apiserver有没加入参数 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 如果kubernetes是二进制安装,在master结点没有安装kube-proxy的情况下,需要在kube-apiserver加入参数enable-aggregator

作者：王继顺 宝尊电商 DBA，主要负责数据库监控告警以及自动化平台的设计开发工作，擅长数据库性能调优、故障诊断。 背景 随着公司各个环境的服务器数量增加，部署有多套 Prometheus（包括生产、测试、Tidb、Kubernetes 等）集群，在一定集群规模下，普通 Prometheus 集群的承载能力会出现短板（查询速度慢、OOM、以及存储空间不够等问题）。加上公司需要保存双十一、双十二等活动期间的监控数据，来统计活动期间同比环比的监控报表。 SO！我们需要有一个统一的查看各个 Prometheus 监控数据的入口，而且具有不受限制的历史数据存储能力的解决方案，经过多个方案的 POC，最终选用 Thanos 的解决方案并和大家分享一下。 Thanos 介绍 Thanos 的主要特性 全局视图：与现有 Prometheus 设置无缝集成，能够跨集群联合，跨所有连接的 Prometheus 服务器的全局查询视图，很好的对 HA 中的 Prometheus 进行容错路由查询。 不受限的保留数据：支持各种对象存储。 压缩和降准采样：对历史数据进行自定义的降准采样以大幅提高查询速度。 实现包括 Prometheus 在内的各个组件高可用。 能够记录规则，实现告警。 Thanos 架构介绍 Thanos 只有一个二进制启动文件，但是根据启动时候的变量不同分为多个组件，结合架构图

前言 该篇文章分享如何将 Python Web 服务融入到Spring Cloud微服务体系中，并调用其服务，Python Web框架用的是Flask 方案 Sidecar + Flask ，在这里，我们会使用 Sidecar 将 Python 接口注册到 SpringCloud 中，将 Python 接口当作 Java 接口进行调用（通过 SpringCloud 去调用 Sidecar ，然后通过 Sidecar 去转发我们的程序请求） Sidecar 是 SpringCloud 提供的一个可将第三方的 rest 接口集成到 SpringCloud 中的工具 Python服务 manage.py import json from flask import Flask, Response, request, make_response, jsonify app = Flask(__name__) @app.route("/health") def health(): result = {'status': 'UP'} return Response(json.dumps(result), mimetype='application/json') @app.route("/getUser") def getUser(): result = {'username': 'python',