Isotio-文档-流量管理
转载自istio文档
流量管理Istio 的流量路由规则可以让您很容易的控制服务之间的流量和 API 调用。Istio 简化了服务级别属性的配置，比如熔断器、超时和重试，并且能轻松的设置重要的任务，如 A/B 测试、金丝雀发布、基于流量百分比切分的概率发布等。它还提供了开箱即用的故障恢复特性，有助于增强应用的健壮性，从而更好地应对被依赖的服务或网络发生故障的情况。
Istio 的流量管理模型源于和服务一起部署的 Envoy 代理。网格内服务发送和接收的所有流量（data plane流量）都经由 Envoy 代理，这让控制网格内的流量变得异常简单，而且不需要对服务做任何的更改。
本节中描述的功能特性，如果您对它们是如何工作的感兴趣的话，可以在架构概述中找到关于 Istio 的流量管理实现的更多信息。本部分只介绍 Istio 的流量管理特性。
流量管理介绍为了在网格中导流，Istio 需要知道所有的 endpoint 在哪和属于哪个服务。为了定位到service registry(服务注册中心)，Istio 会连接到一个服务发现系统。例如，如果您在 Kubernetes 集群上安装了 ...
Istio-文档-概念
转载自istio文档,期间加入自己的实践及理解。
Isito是什么云平台令使用它们的公司受益匪浅。但不可否认的是，上云会给 DevOps 团队带来压力。为了可移植性，开发人员必须使用微服务来构建应用，同时运维人员也正在管理着极端庞大的混合云和多云的部署环境。 Istio 允许您连接、保护、控制和观察服务。
从较高的层面来说，Istio 有助于降低这些部署的复杂性，并减轻开发团队的压力。它是一个完全开源的服务网格，作为透明的一层接入到现有的分布式应用程序里。它也是一个平台，拥有可以集成任何日志、遥测和策略系统的 API 接口。Istio 多样化的特性使您能够成功且高效地运行分布式微服务架构，并提供保护、连接和监控微服务的统一方法。
服务网格是什么？Istio 解决了开发人员和运维人员所面临的从单体应用向分布式微服务架构转变的挑战。了解它是如何做到这一点的可以让我们更详细地理解 Istio 的服务网格。
术语服务网格用来描述组成这些应用程序的微服务网络以及它们之间的交互。随着服务网格的规模和复杂性不断的增长，它将会变得越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、度量 ...
docker desktop之Istio初体验
本文环境为Mac，其中 Docker Desktop中安装的k8s集群环境的版本为v1.19.7，istio v1.8.1
Istio下载安装进入Istio发布页面，下载版本istio-1.8.1-osx.tar.gz，然后解压到/usr/local/istio-1.8.1，可以看到下面包含bin及samples文件夹，bin里包含istioctl命令，samples里包含Istio自带的样例应用的部署配置。
样例演示选择profile=demo，安装命令如下：istioctl install --set profile=demo -y
1234567#会看到如下输出...✔ Istio core installed ✔ Istiod installed ...
controller-client-go机制简介
controller-client-go,个人翻译。
client-go under the hoodclient-go库包含了多种机制，我们可以在开发自定义的controllers的时候使用这些机制。这些机制定义在tools/cache folder库中。下图展示了client-go中的各种组件如何运行以及与我们自定义的controller是如何交互的。
client-go components
Reflector：定义在type Reflector inside package cache,watch着Kubernetes API中具体的resource type(kind)。此功能是在 ListAndWatch 中实现的。watch 的资源可以是内置的k8s资源也可以是自定义的资源。当reflector通过watch API接收到新的资源实例的存在的话，它将通过相关listing API接口获取到新创建的资源，并将其放在Delta Fifo队列中。
Informer：定义在base controller inside package cache将从Delta Fifo队列中 ...
Spring Cloud 系列之负载均衡（五)
鉴于章节（四）文章中引入了拓展思考，在很多场景下，我们需要自定义 Ribbon 的配置，此篇主要 demo 示例为修改 Ribbon 的负载均衡策略。
Ribbon 配置自定义配置自定义可以分为如下两种：
使用 Java 代码自定义 Ribbon 配置，配置指定名称的 Ribbon Client1234567IClientConfig ribbonClientConfig: DefaultClientConfigImplIRule ribbonRule: ZoneAvoidanceRuleIPing ribbonPing: DummyPingServerList<Server> ribbonServerList: ConfigurationBasedServerListServerListFilter<Server> ribbonServerListFilter: ZonePreferenceServerListFilterILoadBalancer ribbonLoadBalancer: ZoneAwareLoadBalancerServerlistUpd ...
Spring Cloud 系列之负载均衡（四）
通过前几篇章节，初步认识了通过 RestTemplate 调用微服务拆分的服务的 rest 请求，进一步引入了通过 Eureka 来实现服务注册于发现（此部分的拓展内容其实还有很多，牵扯到自定义元数据及 Eureka 的自我保护等）。
那么问题来了，在实际的场景中我们会遇到很多服务端其实是存在多个副本以实现高可用，那么客户端的请求是如何做分发控制的呢？当然，朋友你肯定第一个想到的是老毛子搞的 nginx。Nice！！nginx 确实很强大，基于 nginx 我们能做很多事情【后续我也会对 nginx 做进一步的分享：）】。在 Spring Cloud 生态圈，其实大佬们早已准备好了开箱即用的组件，就是今天的主角：**Riboon**。
Eureka 与 Ribbon 配合的架构图
服务消费者microservice-consumer-movie-ribbon将之前的 microservice-consumedr-movie 整合 Ribbon 改造下。
pom 文件由于此微服务还是 Eureka 的 Client 端，所以依赖中还是会存在 eureka client 的依赖，同时加 ...
Spring Cloud 系列之服务注册与发现（三）
鉴于上篇内容提出的思考拓展部分，此部门其实就是做了 application.yaml 的配置文件的更改。此篇的 Demo 通过单节点多端口来模拟多节点分布的 Eureka Server HA 集群。由于篇幅比较简单，我就直接将 microservice-discovery-eureka 做了 yaml 配置文件更改最终输出为 microservice-discovery-eureka-ha 的模块，就暂且不实现生产者服务和消费者服务了。
Eureka Server HAmicroservice-discovery-eureka-ha
application.yaml 文件如下:
12345678910111213141516171819202122232425262728293031323334spring: application: name: microserver-discovery-eureka-ha#eureka:# client:# service-url:# defaultZone: http://peer1:8001&#x ...
Spring Cloud系列之服务注册与发现（二）
鉴于上篇初识（一）引入如下思考：如果每个组件的服务分布在不同的节点，那么通过每次的硬编码去实现域名（服务识别）解析是多么痛苦的一件事，况且还没有涉及到服务的主动发现。这个时候我们急需引用一种方案来解决此问题，那么此阶段我将引入 EureKa 的应用。而在 Dubbo 体系中是通过 Zookeeper 集群来实现服务注册与发现的，后续有机会将会对 Dubbo 做学习与分析。
Eureka 架构通过架构图我们会发现实际上 Eureka 包含两个组件：Eureka Server 和 Eureka Client，它们的作用如下：
Eureka Server 提供服务发现的能力（这种能力个人理解是被动的），即各个微服务启动的时候会主动向 Server 注册自己的信息（例如IP、端口、微服务名称等）
Eureka Client 则是一个客户端，与 Eureka Server 进行交互
微服务启动后会周期性的（默认为30s）向 Server 端发送心跳，以证明自己是存活状态，以此“续约”租期
如果 Server 端在一定时间内未接收到某个微服务发送的心跳，则 Server 会注销该实例（默认为90 ...
Spring Cloud系列之初识(一)
初识由于是开篇，先撇开springcloud的各种核心组件，来个demo 简单的认知下。话不多说直接开撸。
场景简单场景如下图
编写服务提供者microservice-simple-provider-user
引入pom依赖文件如下：12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi ...
kubernetes跨namespace资源借用及资源归还控制
需求背景 在多租户的场景下，提供一种跨namespace的资源“借用”途径，在资源池建设之后进一步提升资源的利用率。在还资源过程中，期望能够控制对原来跨ns借用资源的应用进行“延迟”释放，控制驱逐Pod的顺序，保障原来优先级较高的应用不会被优先处理。
用户故事应用类别分为 训练任务和在线任务。训练任务一般采用分布式训练，但是其Pod副本数是可以适当弹性浮动的，即比如副本数为3~6之间都可以接受。在线服务可以理解为服务可能在用户开通之后就一直存在，客观情况下除非用户主动删除在线服务，否则在资源满足的情况下不会主动释放其占用的服务。简单描述即当资源可能不够的情况下，在需要自动释放资源的时候，在线服务是 “延迟” 释放资源，优先对那些训练任务“动手”。
用户A配置了 {resources:{min:6, max:10}} 的资源限额，用户B的资源限额配置为 {resources: {min:12,max:14}}
用户A Job 应用资源配置为{resources:{requests:2,limits:2}} rs为2，NoteBook 应用资源配额为{resources:{request ...