<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Service Mech on Cylon&#39;s Collection</title>
    <link>https://www.161616.top/tags/service-mech/</link>
    <description>Recent content in Service Mech on Cylon&#39;s Collection</description>
    <generator>Hugo -- 0.125.7</generator>
    <language>zh</language>
    <lastBuildDate>Wed, 22 Mar 2023 23:00:36 +0800</lastBuildDate>
    <atom:link href="https://www.161616.top/tags/service-mech/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>istio sidecar流量处理机制及配置</title>
      <link>https://www.161616.top/istio-sidecar-mechnisim/</link>
      <pubDate>Sat, 09 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://www.161616.top/istio-sidecar-mechnisim/</guid>
      <description>sidecar 介绍 在istio的流量管理等功能，都需要通过下发的配置应用到应用运行环境执行后生效，负责执行配置规则的组件在service mesh中承载应用代理的实体被称为side-car
Istio对流量策略管理等功能无须对应用程序做变动，
这种对应用服务完全非侵入的方式完全依赖于Side-car，应用的流量有Sidecar拦截并进行认证、鉴权、策略执行等治理功能。在Kubernetes平台中，Side-car容器于应用容器在同一个Pod中并共享网络名词控件，因此Side-car容易可以通过iptables规则拦截进出流量进行管理。
sidecar的注入 sidecar是service mesh无侵入式架构的应用模式，在使用sidecar部署服务网格时，无需再每个应用节点运行服务代理，但是需要在每个应用程序中部署一个sidecar容器，来接管所有进出流量。
Sidecar会将额外容器注入到 Pod 模板中。Istio中的数据平面组件所需的容器有：
istio-init 用于设置容器的iptables规则，目的是为了接管进出流量。在应用容器前启动并运行完成其生命周期，多个init容器按顺序依次完成。 istio-proxy 基于envoy的sidecar的代理。 sidecar被注入的方式 手动注入，使用 istioctl 修改容器模板并添加前面提到的两个容器的配置。不论是手动注入还是自动注入，Istio 都从 istio-sidecar-injector 和的 istio 两个 Configmap 对象中获取配置。 refer-istio-sidecar-injector
自动注入，在部署应用是，istio自动将sidecar注入到pod。这是istio推荐的方法，Istio在基于Kubernetes平台之上，需要在部署应用之前，对要标记部署应用程序的名称空间标记 kubectl label namespace default istio-injection=enabled 这个操作是对名称空间级别生效的。而后所部署的Pod中会注入sidecar执行上面sidecar容器的操作。
istio injector 注入原理 Sidecar Injector是Istio中实现自动注入Sidecar的组件，它是以Kubernetes准入控制器 AdmissionController 的形式运行的。Admission Controller 的基本工作原理是拦截Kube-apiserver的请求，在对象持久化之前、认证鉴权之后进行拦截。
Admission Controller有两种：一种是内置的，另一种是用户自定义的。
Kubernetes允许用户以Webhook的方式自定义准入控制器，Sidecar Injector就是这样一种特殊的MutatingAdmissionWebhook。
Sidecar Injector只在创建Pod时进行Sidecar容器注入，在Pod的创建请求到达 Kube-apiserver 后，首先进行认证鉴权，然后在准入控制阶段，Kube-apiserver以REST的方式同步调用Sidecar Injector Webhook服务进行init与istio-proxy容器的注入，最后将Pod对象持久化存储到etcd中。
sidecar容器 sidecar容器内部运行着 pilot-agent 与 envoy
Pilot-agent：基于kubernetesAPI资源对象为envoy初始化可用的bootstrap配置进行启动，在运行后管理envoy运行状态，如配置变更，出错重启等。
envoy：数据平面的执行层，由 pilot-agent 所启动的，从xDS API动态获取配置信息。Envoy并通过流量拦截机制处理入栈及出栈的流量。
envoy的listener 在运行在Kubernetes平台之上的istio，Envoy是通过Pilot将Kubernetes CRD资源 DestnationRule VirtualService Gateway等资源提供的配置，生成对应的Envoy配置。</description>
    </item>
    <item>
      <title>istio部署问题Q&amp;A</title>
      <link>https://www.161616.top/istio-deployment-qa/</link>
      <pubDate>Sun, 03 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://www.161616.top/istio-deployment-qa/</guid>
      <description>端口绑定无权限 创建Gateway，提示绑定端口无权限。
text 1 2 3 2020-12-27T12:25:30.974288Z	warning	envoy config	gRPC config for type.googleapis.com/envoy.config.listener.v3.Listener rejected: Error adding/updating listener(s) 0.0.0.0_90: cannot bind &amp;#39;0.0.0.0:90&amp;#39;: Permission denied 问题原因：容器内默认权限不能使用非特权端口（&amp;lt;1024
导出部署清单部署失败 bash 1 istioctl manifest generate &amp;gt; generated-manifest.yaml 如果尝试使用来安装和管理Istio istioctl manifest generate，请注意以下警告：
Istio名称空间（istio-system默认情况下）必须手动创建。 istioctl install 会从Kubernetes上下文中自动检测特定于环境的设置。如需手动安装需要执行如下步骤： --set values.global.jwtPolicy=third-party-jwt --set values.global.jwtPolicy=first-party-jwt refer
token
Generate a manifest</description>
    </item>
    <item>
      <title>istio流量管理：非侵入式流量治理</title>
      <link>https://www.161616.top/istio-introduction/</link>
      <pubDate>Wed, 30 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://www.161616.top/istio-introduction/</guid>
      <description>在服务治理中，流量管理是一个广泛的话题，一般情况下，常用的包括：
动态修改服务访问的负载均衡策略，比如根据某个请求特征做会话保持； 同一个服务有多版本管理，将一部分流量切到某个版本上； 对服务进行保护，例如限制并发连接数、限制请求数、隔离故障服务实例等； 动态修改服务中的内容，或者模拟一个服务运行故障等。 在Istio中实现这些服务治理功能时无须修改任何应用的代码。较之微服务的SDK方式，Istio以一种更轻便、透明的方式向用户提供了这些功能。用户可以用自己喜欢的任意语言和框架进行开发，专注于自己的业务，完全不用嵌入任何治理逻辑。只要应用运行在Istio的基础设施上，就可以使用这些治理能力。
总结Istio流量治理的目标：以基础设施的方式提供给用户非侵入的流量治理能力，用户只需关注自己的业务逻辑开发，无须关注服务访问管理。
istio流量治理的核心组件Pilot 在istio1.8中，istio的分为 envoy （数据平面） 、istiod （控制平面） 、addons（管理插件） 及 istioctl （命令行工具，用于安装、配置、诊断分析等操作）组成。
Pilot是Istio控制平面流量管理的核心组件，管理和配置部署在Istio服务网格中的所有Envoy代理实例。
pilot-discovery为envoy sidecar提供服务发现，用于路由及流量的管理。通过kubernetes CRD资源获取网格的配置信息将其转换为xDS接口的标准数据格式后，通过gRPC分发至相关的envoy sidecar
Pilot组件包含工作在控制平面中的 pilot-discovery 和工作与数据平面的pilot-agent 与Envoy(istio-proxy)
pilot-discovery主要完成如下功能：
从service registry中获取服务信息 从apiserver中获取配置信息。 将服务信息与配置信息适配为xDS接口的标准数据格式，通过xDS api完成配置分发。 pilot-agent 主要完成如下功能
基于kubernetes apiserver为envoy初始化可用的boostrap配置文件并启动envoy。
管理监控envoy的云兄状态及配置重载。
envoy
每个sidecar中的envoy是由pilot-agent基于生产的bootstrap配置进行启动，并根据指定的pilot地址，通过xDS api动态获取配置。 sidecar形式的envoy通过流量拦截机制为应用程序实现入站和出站的代理功能。 Pilot的实现 在istio中的管理策略都是基于Kubernetes CRD的实现，其中有关于流量管理的CRD资源包括 VirtualService EnvoyFilter Gateway ServiceEntry Sidecar DestinationRule WorkloadEntry WorkloadGroup。reference istio-networking-crd-resouces
VirtualServices：用于定义路由，可以理解为envoy的 listener =&amp;gt; filter =&amp;gt; route_config
DestinationRule：用于定义集群，可以理解为envoy 的 cluster
Gateway：用于定义作用于istio-ingress-gateway
ServiceEntry：用于定义出站的路由，作用于istio-egress-gateway
EnvoyFilter：为envoy添加过滤器或过滤器链。
Sidecar：用于定义运行在sidecar之上的envoy配置。
Virtual Services和 Destination Rules是Istio流量路由功能的核心组件</description>
    </item>
    <item>
      <title>istio安装</title>
      <link>https://www.161616.top/istio-install/</link>
      <pubDate>Thu, 20 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://www.161616.top/istio-install/</guid>
      <description>Istio用于提供统一方式来集成微服务的开放平台，管理微服务之间的流量，执行策略和汇总遥测数据。Istio的控制平面在基础集群管理平台（例如Kubernetes）上提供了一个抽象层。
Istio组成：
在Istio1.8中，istio由以下组件组成：istio-component
istio服务网格分为数据平面和控制平面
数据平面：数据平面是由一组代理组成
envoy：Sidecar Proxy 每个微服务代理来处理入口/出口业务服务之间的集群中，并从外部服务的服务。代理形成一个*安全的微服务网格，*提供了丰富的功能集合 控制平面：管理与配置代理的流量规则。
istiod：istio的控制平面，提供了服务发现，配置和证书管理，包含如下组件： Pilot ：负责运行时配置，（服务发现，智能路由） Citadel：负责证书的颁发与轮替 Galley：负责配置的管理（验证，提取，分发等功能） istio卸载
bookinfo卸载
text 1 kubectl delete -f samples/bookinfo/platform/kube/bookinfo.yaml istio卸载
text 1 istioctl manifest generate|kubectl delete -f - addons
text 1 2 3 4 kubectl delete -f samples/addons/prometheus.yaml kubectl delete -f samples/addons/jaeger.yaml kubectl delete -f samples/addons/kiali.yaml kubectl delete -f samples/addons/grafana.yaml </description>
    </item>
    <item>
      <title>istio命令</title>
      <link>https://www.161616.top/istio-cli/</link>
      <pubDate>Thu, 20 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://www.161616.top/istio-cli/</guid>
      <description>显示配置文件中的差异 istioctl profile diff default demo
显示对应配置的profile istioctl profile dump demo
显示可用的配置 istioctl profile list
安装指定配置的istio istioctl install --set profile=demo
生成配置清单 istioctl manifest generate
istioctl验证安装: istioctl manifest generate --set profile=demo |istioctl verify-install -
istio的非侵入式流量治理
流量治理是一个非常宽泛的话题，例如：
◎ 动态修改服务间访问的负载均衡策略，比如根据某个请求特征做会话保持；
◎ 同一个服务有两个版本在线，将一部分流量切到某个版本上；
◎ 对服务进行保护，例如限制并发连接数、限制请求数、隔离故障服务实例等；
◎ 动态修改服务中的内容，或者模拟一个服务运行故障等。
在Istio中实现这些服务治理功能时无须修改任何应用的代码。较之微服务的SDK方式，Istio以一种更轻便、透明的方式向用户提供了这些功能。用户可以用自己喜欢的任意语言和框架进行开发，专注于自己的业务，完全不用嵌入任何治理逻辑。只要应用运行在Istio的基础设施上，就可以使用这些治理能力。 一句话总结 Istio 流量治理的目标：以基础设施的方式提供给用户非侵入的流量治理能力，用户只需 关注自己的业务逻辑开发，无须关注服务访问管理。
istio服务架构 在istio1.8中，istio的分为 envoy （数据平面） 、istiod （控制平面） 、addons（管理插件） 及 istioctl （命令行工具，用于安装、配置、诊断分析等操作）组成。
Pilot Pilot是Istio控制平面流量管理的核心组件，管理和配置部署在Istio服务网格中的所有Envoy代理实例。
pilot-discovery为envoy sidecar提供服务发现，用于路由及流量的管理。通过kubernetes CRD资源获取网格的配置信息将其转换为xDS接口的标准数据格式后，通过gRPC分发至相关的envoy sidecar
Pilot组件包含工作在控制平面中的 pilot-discovery 和工作与数据平面的pilot-agent 与Envoy(istio-proxy)
pilot-discovery主要完成如下功能：
从service registry中获取服务信息 从apiserver中获取配置信息。 将服务信息与配置信息适配为xDS接口的标准数据格式，通过xDS api完成配置分发。 pilot-agent 主要完成如下功能</description>
    </item>
  </channel>
</rss>
