最小轻量级的Istio来了,仅使用流量治理能力

Istio 1.0.1作为8月份的版本已经发布,主要修复了1.0版本发布以来发现的一些关键Issue.官网的release note(https://istio.io/about/notes/1.0.1/)列出了Istio1.0和1.0.1的差别
Istio涉及的组件和CRD较多,Istio 1.0 中包含了 51 个 CRD,组件包括pilot,galley,policy,telemetry,citadel和许多插件,对想快速试用Istio的同学来说比较困难。

Istio 1.0.1允许部署一个仅包含Pilot组件的最小轻量级的Istio。对想快速上手Istio和只想使用Istio流量治理功能的同学带来了福音。Istio的流量治理功能非常强大,包括配置请求路由,设置请求超时,重试,熔断,故障注入,实现灰度发布等。

下面让我们一起看下如何安装一个最小化的Istio:
首先需要一个已经安装了Kubernetes的环境,并下载Istio1.0.1版本(https://github.com/istio/istio/releases/tag/1.0.1)。

步骤:

  1. 如果使用2.10.0之前的Helm版本,可以通过kubectl apply命令安装Istio的Custom Resource Definitions,等待几秒直到CRDs提交至kube-apiserver:

kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml

  1. 通过helm template安装,渲染Istio核心组件到istio-minimal.yaml(Kubernetes manifest文件) :

helm template install/kubernetes/helm/istio --name istio --namespace istio-system \
--set security.enabled=false \
--set ingress.enabled=false \
--set gateways.istio-ingressgateway.enabled=false \
--set gateways.istio-egressgateway.enabled=false \
--set galley.enabled=false \
--set sidecarInjectorWebhook.enabled=false \
--set mixer.enabled=false \
--set prometheus.enabled=false \
--set global.proxy.envoyStatsd.enabled=false \
--set pilot.sidecar=false > $HOME/istio-minimal.yaml

  1. 创建istio-system 的命名空间:
    kubectl create namespace istio-system
  2. 通过第2步生成的manifest安装pilot组件:
    kubectl apply -f $HOME/istio-minimal.yaml
  3. 检查istio-pilot-* pod 是否部署成功:
    kubectl get pods -n istio-system
    NAME READY STATUS RESTARTS AGE
    istio-pilot-58c65f74bc-2f5xn 1/1 Running 0 1m

只需要5步就可以成功安装一个最小化的Istio,是不是很简单?赶快尝试一下吧,
最后卸载Istio也很方便:
kubectl delete -f $HOME/istio-minimal.yaml
kubectl delete -f install/kubernetes/helm/istio/templates/crds.yaml -n istio-system

原文地址:http://blog.51cto.com/13831707/2173854

时间: 2024-08-30 16:05:41

最小轻量级的Istio来了,仅使用流量治理能力的相关文章

Istio 流量治理功能原理与实战

一.负载均衡算法原理与实战 负载均衡算法(load balancing algorithm),定义了几种基本的流量分发方式,在Istio中共有4种标准负载均衡算法. ?Round_Robin: 轮询算法,顾名思义请求将会依次发给每一个实例,来共同分担所有的请求. ?Random: 随机算法,将所有的请求随机分发给健康的实例 ?Least_Conn: 最小连接数,在所有健康的实例中任选两个,将请求发给连接数较小的那一个实例. 接下来,我们将根据以上几个算法结合APM(应用性能管理)的监控拓扑图来实

idou老师教你学Istio 19 : Istio 流量治理功能原理与实战

一.负载均衡算法原理与实战 负载均衡算法(load balancing algorithm),定义了几种基本的流量分发方式,在Istio中一共有4种标准负载均衡算法. ?Round_Robin: 轮询算法,顾名思义请求将会依次发给每一个实例,来共同分担所有的请求. ?Random: 随机算法,将所有的请求随机分发给健康的实例 ?Least_Conn: 最小连接数,在所有健康的实例中任选两个,将请求发给连接数较小的那一个实例. 接下来,我们将根据以上几个算法结合APM(应用性能管理)的监控拓扑图来

割边最少的最小割求法两种(仅结论)

我太弱了,所以只贴上结论,省略(不会)证明. 求法一: 1.求出原网络的最大流. 2.把可能的关键割边(即满流的边)容量置为 1,其余边容量置为 0. 3.求出修改后网络的最大流. 此时的最大流即是最小割时最少的割边数. 总共求了 2 次最大流. 更好的求法二: 以下用 E 表示网络流中的边数. 1.建图时,把每条边的边权 w 置为 w * (E + 1) + 1. 2.求出修改后网络的最大流 flow_max. 此时原图的最大流为 flow_max / (E + 1) ,最少的割边数为 flo

2020云原生7大趋势预测!

2020云原生7大趋势预测! 过去的几年,是云原生技术和理念得到广泛接受的几年.在这个快速发展的领域,预测未来显得尤其困难,但是我们又有着一些坚定的信念,相信以开放创新为支撑的云原生领域会持续重塑软件生命周期,带来不断的价值. 2019,在众多热门技术趋势中,云原生的关注度居高不下,很多开发者都对由此而兴起的一众技术十分追捧,众多企业开始探索云原生架构转型落地.在中国,开发者们经历了从关注“云原生概念”到关注“云原生落地实践”的转变. 在筹备阿里云首届云原生实践峰会的过程中,我们展开了对云原生技

云原生时代,微服务到底应该怎么玩儿?

在微服务诞生之初,并没有太多方案的选择:选一个注册中心用来做服务注册和发现,通过客户端SDK进行负载均衡和容错,再搭配上日志.监控.调用链全套观测手段,一套微服务架构便建立起来了. 作为最流行的业务开发语言,Java体系里诞生了很多微服务架构,例如Spring Cloud.使用Spring Cloud,Spring技术栈的开发人员可以快速的开发和管理微服务,丰富的功能让其他语言体系的开发者们羡慕不已. 在云原生时代,Kubernetes快速普及,除了解决微服务所需要的应用编排.伸缩.保活等功能外

【转】【C#】【Thread】Interlocked 轻量级锁

为什么说它是轻量级呢?因为它仅对整形数据(即int类型,long也行)进行同步. 具体使用如下表: Interlocked.Increment(ref value) 数值加一(原子性操作) Interlocked.Decrement(ref value) 数值减一(原子性操作) Interlocked.Exchange(ref value1, value2) 交换:把值2赋给值1:返回新值 Interlocked.CompareExchange(ref value1, value2, value

C#【Thread】Interlocked 轻量级锁

什么说它是轻量级呢?因为它仅对整形数据(即int类型,long也行)进行同步. 具体使用如下表: Interlocked.Increment(ref value) 数值加一(原子性操作) Interlocked.Decrement(ref value) 数值减一(原子性操作) Interlocked.Exchange(ref value1, value2) 交换:把值2赋给值1:返回新值 Interlocked.CompareExchange(ref value1, value2, value3

线程----轻量级同步Interlocked

字段与属性: 字段通常都是为类的方法所使用,而属性则常用于表示类的状态(比如StringBuilder的  Length),类的能力(比如StringBuilder的 Capacity),方法进行的状态或者阶段 对象的原子性: 对象的状态是一个整体,如果一个字段改变.其他的字段也要同时做出相应的改变.简单  的来说,就是要么不改,要么全改 对象的常量性: 对象的状态一旦确定,就不能再次更改了.如果想再次更改,需要重新构造一个对象  轻量级同步Interlocked 为什么说它是轻量级呢?因为它仅

bzoj 1497 最大获利 - 最小割

新的技术正冲击着手机通讯市场,对于各大运营商来说,这既是机遇,更是挑战.THU集团旗下的CS&T通讯公司在新一代通讯技术血战的前夜,需要做太多的准备工作,仅就站址选择一项,就需要完成前期市场研究.站址勘测.最优化等项目.在前期市场调查和站址勘测之后,公司得到了一共N个可以作为通讯信号中转站的地址,而由于这些地址的地理位置差异,在不同的地方建造通讯中转站需要投入的成本也是不一样的,所幸在前期调查之后这些都是已知数据:建立第i个通讯中转站需要的成本为Pi(1≤i≤N).另外公司调查得出了所有期望中的