yevvzi的博客

在今年五月份社区已经添加了 MCP-OVER-XDS的实现 ，在当前的master代码中已经 移除了mcp 协议 的实现代码，将全部转换为MCP-OVER-XDS实现，也就意味着istio 1.9将不再支持原有MCP协议，具体参考 XDS-OVER-MCP设计initConfigSources当我们配置的ConfigSource为XDS类型时，将创建XDS client,用于发起请求// 初始化一个ads clientxdsMCP, err := adsc.New(srcAddress.Host,

环境准备使用kind进行集群安装，通过静态路由打通两个集群的容器网络。cluster1 初始化cluster1 kind配置如下kind: ClusterapiVersion: kind.x-k8s.io/v1alpha4featureGates: GenericEphemeralVolume: truenetworking: podSubnet: "10.241.0.0/16" serviceSubnet: "10.95.0.0/16"nodes:- role: contro

概述Istio 在网格中部署的Pod中注入initContainer，istio-init。该istio-init容器设置荚的网络流量重定向到/从Istio三轮代理。这就要求将用户或服务帐户部署到网格上的Pod具有足够的Kubernetes RBAC权限才能部署具有NET_ADMIN和NET_RAW功能的容器。对于某些组织的安全合规性，要求Istio用户具有提升的Kubernetes RBAC权限是有问题的。Istio CNI插件是istio-init执行相同网络功能但不要求Istio用户启用提升的Kub

envoy rbac介绍基于角色的访问控制(RBAC)为服务提供服务级别和方法级别的访问控制。RBAC政策是附加的。依次检查策略。根据操作以及是否找到匹配的策略，允许或拒绝请求。策略配置主要包括两个部分。permissions由AuthorizationPolicy中to转换过来定义角色的权限集。 每个权限都与OR语义匹配。 为了匹配此策略的所有操作，应使用any字段设置为true的单个Permission。principals由AuthorizationPolicy中to和when

介绍MCP是基于订阅的配置分发API。配置使用者（即sink）从配置生产者（即source）请求更新资源集合.添加,更新或删除资源时，source会将资源更新推送到sink.sink积极确认资源更新，如果sink接受，则返回ACK，如果被拒绝则返回NACK，例如: 因为资源无效。一旦对先前的更新进行了ACK/NACK，则源可以推送其他更新.该源一次只能运行一个未完成的更新(每个集合).MCP是一对双向流gRPC API服务（ResourceSource和ResourceSink）。当source是

变更说明涉及以下变更：流量管理添加了 values.global.proxy.holdApplicationUntilProxyStarts config选项，它使sidecar注入器在pod容器列表的开始处注入sidecar，并将其配置为阻止所有其他容器的开始，直到代理就绪为止。默认情况下禁用此选项。(#11130)新增了对用于客户端证书和CA证书的SDS支持，该证书用于使用DestinationRule从Egress Gateway发起的TLS/mTLS(#14039)安全改进

介绍在使用k8s的过程中在特定场景可能需要控制pod的执行顺序，接下来我们将学习各个开源组件的实现方式istio中的实现今天在测试istio新功能时注意到istio中添加了values.global.proxy.holdApplicationUntilProxyStarts，使sidecar注入器在pod容器列表的开始处注入sidecar，并将其配置为阻止所有其他容器的开始，直到代理就绪为止。在查看代码后发现对istio-proxy容器注入了以下内容。 lifecycle:

在本文中,您将学习如何在Pod启动或关闭时防止断开的连接.您还将学习如何正常关闭长时间运行的任务.在Kubernetes中,创建和删除Pod是最常见的任务之一.当您执行滚动更新,扩展部署,每个新版本,每个作业和cron作业等时,都会创建Pod.但是在驱逐后,Pods也会被删除并重新创建-例如,当您将节点标记为不可调度时.如果这些Pod的性质如此短暂,那么当Pod在响应请求时却被告知关闭时会发生什么呢？请求在关闭之前是否已完成？接下来的请求又如何呢？在讨论删除Pod时会发生什么之前,有必要讨.

介绍flagger是一个k8s operator,可以基于多种ingress 实现金丝雀升级，以进行流量转移,并使用Prometheus指标进行流量分析。canary分析器可以通过webhooks进行扩展，以运行系统集成/验收测试，负载测试或任何其他自定义验证。Flagger实现了一个控制环路，该环路逐渐将流量转移到金丝雀，同时测量关键性能指标，例如HTTP请求成功率，请求平均持续时间和Pod运行状况。 基于对KPI的分析，金丝雀会被提升或中止.工作原理flaager 可以通过自定义canary资

介绍Open Service Mesh（OSM）是一种轻量级，可扩展的Cloud Native服务网格，它使用户能够统一管理，保护和获得针对高度动态微服务环境的开箱即用的可观察性功能。安装osmwget https://github.com/openservicemesh/osm/releases/download/v0.1.0/osm-v0.1.0-darwin-amd64.tar.gztar xf osm-v0.1.0-darwin-amd64.tar.gz# pre check./dar

envoy 中的证书验证combined_validation_context组合的证书验证上下文包含默认的CertificateValidationContext和SDS配置。 当SDS服务器返回动态CertificateValidationContext时，动态和默认的CertificateValidationContext都将合并到新的CertificateValidationContext中以进行验证。 此合并是通过Message::MergeFrom()完成的，因此动态的Certifica

环境这里我们是在本机使用kind，安装查看容器对应的虚拟设备对for container in `crictl ps -q`doiflink=`crictl exec $container cat /sys/class/net/eth0/iflink`iflink=`echo $iflink|tr -d '\r'`veth=`grep -l $iflink /sys/class/net/*/ifindex`veth=`echo $veth|sed -e 's;^.*net/\(.*\)/if

tekton中以pod为Task的运行单元，而Task中的step实际就是一个个pod,其中用到了许多容器用于进行初始化动作，本文将分析各个容器在tekton task运行时起到的作用entrypoint-image包含entrypoint 可执行文件的image，默认值"override-with-entrypoint:latest"，在task pod启动时，会将/ko-app/entrypoint拷贝到具体step的/tekton/tools/entrypoint目录，作为首先调用的命令，将使用该

Knative有两个组件，可以独立安装或一起使用。为了帮助您挑选适合自己的组件，以下是每个组件的简要说明：Serving 为基于无状态请求的服务提供了一种零扩展抽象。Eventing提供了抽象来启用绑定事件源（例如Github Webhooks，Kafka）和使用者（例如Kubernetes或Knative Services）的绑定。Knative还具有一个Observability插件，该插件提供了标准工具，可用于查看Knative上运行的软件的运行状况本文将安装Serving后运行一个hel

envoy ratelimitenvoy 可以继承一个全局grpc ratelimit 服务，称之为为rate limit service，go-control-plane 是一个官方实现的golang 库github.com/envoyproxy/go-control-planego-control-plane中关于rls的pb文件为envoy/service/ratelimit/v2/rls.pb.go其包含了一个RegisterRateLimitServiceServer方法，将一个限流器实现

Readiness Gateskubernetes从1.11版本开始引入了Pod Ready++特性对Readiness探测机制进行扩展，在1.14版本时达到GA稳定版本，称其为Pod Readiness Gates。通过Pod Readiness Gates机制，用户可以将自定义的ReadinessProbe探测方式设置在Pod上，辅助kubernetes设置Pod何时达到服务可用状态Ready，为了使自定义的ReadinessProbe生效，用户需要提供一个外部的控制器Controller来设置相应

triggertrigger使用户能够将事件有效负载中的字段映射到资源模板中。 换句话说，这允许事件既可以建模也可以将实例化为Kubernetes资源。 对于tektoncd/pipeline，这使得将配置封装到PipelineRuns和PipelineResources中变得容易。安装kubectl apply --filename https://storage.googleapis.com/tekton-releases/triggers/latest/release.yamlTrigger

总览PipelineRun允许您实例化并执行集群内管道。管道按所需的执行顺序指定一个或多个任务。 PipelineRun按照指定的顺序在管道中执行任务，直到所有任务成功执行或发生故障为止。注意：PipelineRun自动为管道中的每个任务创建相应的TaskRun。Status字段跟踪PipelineRun的当前状态，并可用于监视进度。 此字段包含每个TaskRun的状态，以及用于实例化此PipelineRun的完整PipelineSpec，以实现全面的可审核性。配置PipelineRun必要字段

pipline总览PipelineRun允许您实例化并执行集群上的。A 以所需的执行顺序Pipeline指定一个或多个Tasks。一个PipelineRun 执行Tasks中Pipeline，直到所有的顺序，他们被指定Tasks已成功执行或出现故障。注意： A会PipelineRun自动TaskRuns为中的每个 创建对应Task的内容Pipeline。该Status字段跟踪的当前状态PipelineRun，并可用于监视进度。此字段包含每个的状态TaskRun，以及PipelineSpec用于实例化此

taskrun一个TaskRun定义支持以下领域：需要：apiVersion-指定API版本，例如 tekton.dev/v1beta1。kind-将此资源对象标识为TaskRun对象。metadata-指定TaskRun唯一标识的元数据，例如name。spec-指定TaskRun的配置。taskRef或taskSpec -指定TaskRun将执行的tasks。可选的：serviceAccountName-指定一个ServiceAccount对象，该对象提供TaskRun用于执行