Raymond的博客

由一个控制器和一组CRD组成，可为Kubernetes提供高级部署功能，包括支持与Ingress Controller（Nginx和ALB）及ServiceMesh（Istio、Linkerd和SMI）集成，利用它们的流量治理能力实现流量迁移过程能够查询和解释来自多种指标系统（Prometheus、Kubernetes Jobs、Web、Datadog等）的指标来验证Blue-Green或Canary部署结果，并根据结果自动决定执行升级或回滚几个相关的CRD基本工作机制。

同步选项（Sync Options）用于禁用或启用同步过程中的某些特性资源修剪传播策略，默认使用foreground策略另外可选的策略还有background和orphanPruneLastReplaceValidation设定同步策略启用自动同步d自动修剪自动自我修复设定同步选项禁止修剪特定的资源禁用kubectl验证有选择地执行同步（两种途径之一）命令：argocd app set --sync-option ApplyOutOfSyncOnly={true|false}

ArgoCD有两种部署方式：多租户部署和核心化部署多租户常用于为多个应用程序开发团队提供服务，并由平台团队维护的场景有两类可选择的部署方式支持用户通过Web UI或CLI进行访问支持集群级部署和名称空间级两种安装机制核心化部署安装的组件较小且更易于维护，它不包含API Server和UI，且不提供高可用机制仅适用于独立使用ArgoCD且不需要多租户特性的集群管理员用户要通过Kubernetes的访问权限来管理ArgoCD。

ArgoCD是什么？将应用程序部署到Kubernetes之上的GitOps工具核心组件：Application Controller及相关的一组CRD基础工作模型以特定Repository（配置仓库）为应用程序部署和管理的惟一可信源，该Repository负责定义Application的期望状态Application Controller负责将Repository中定义的Application运行于一个特定的目标Kubernetes Cluster之上。

案例环境说明示例项目：http://code.raymonds.cc/root/spring-boot-helloworld.git触发机制。

Tekton Triggers简介监控特定的事件，并在满足条件时自动触发Tekton Pipeline；Tekton Triggers为用户提供了一种声明式APITekton Triggers的关键组件（CRD）

【代码】y159.第九章 GitOps从入门到精通 -- 实战案例Source-2-Image(八）

使用taskRef或taskSpec可将Task添加至Pipeline上，它们以列表形式定义在spec.tasks字段中；对于这些Task的运行，它们允许用户使用when表达式来为其添加执行条件使用conditions添加限制条件（已弃用）使用timeout定义任务超时时长使用runAfter定义任务的执行顺序定义finally任务，定义一个最终任务使用retries定义重试次数。

Workspace是什么？Workspace用于为Task中的各Step提供工作目录，基于该Task运行的TaskRun需要在运行时提供该目录TaskRun的实际运行形式为Pod，因而Workspace对应的实际组件为Pod上的VolumeWorkspace的功用跨Task共享数据借助于Secrets加载机密凭据借助于ConfigMap加载配置数据持久化存储数据为Task提供缓存以加速构建过程。

单分支策略简介通常也称为Feature Branch Workflow，其中Master Branch承载项目变更历史研发人员创建短生命周期的Feature分支，完成Feature目标相关的研发任务Feature开发完成后，通过PR流程，请求将代码合并至Master BranchPR得到确认后，CI Pipeline 即被触发，直至最后将Image推送至Registry单分支模型相关的CI示意图单分支策略适配“单流水线”模型。

在Pipeline上，各Task的次序可在引用的Task上通过runAfter字段进行定义未通过runAfter明确指定顺序的各Task将以并行方式运行。

环境要求Tekton Pipelines 0.11.0及以上的版本，需要运行于Kubernetes v1.15以上的集群中；集群上要启用了RBAC鉴权插件；拥有管理员权限（绑定到了clusterrole/cluster-admin）的用户；初始化kubeadm部署Tekton Pipelines根据Tekton Pipelines项目提供的配置文件完成部署Tekton Pipelines会部署controller和webhook两个应用部署Tekton Dashboard添加域名解析。

对于一个特定的应用，其声明式配置清单的管理会涉及到诸多方面Dockerfile：将应用程序打包成Docker ImageKubernetes资源配置文件：Deployments、Services、Volumes和ConfigMaps等；环境相关管理策略，例如应用的冗余数量，在预发和生产环境可能会有所不同；与容灾相关的跨区可用性策略相关的调度机制；网络安全策略；路由策略；……这些信息分别来自。

CI/CD是一种在应用开发阶段引入自动化实现以较高频度向客户交付应用的方法广为接受的模型，存在三个典型阶段：持续集成、持续交付和持续部署CI/CD可以让持续自动化和持续监控贯穿于应用的整个生命周期（从集成到测试、到交付，再到部署）这些关联的事务通常被统一称作CI/CD Pipeline，它一般需要由开发和运维团队以敏捷方式协同支持CI/CD是什么，到早期的瀑布式开发到后来的敏捷开发，CI/CD在所谓的应用自动化软件的交付阶段是个非常重要的包括构建和集成阶段是非常重要的概念，它是在应用开发阶段引入的自动化实现

上面的部署步骤会于knative-eventing名称空间下创建kafka-controller、kafka-broker-receiver、kafka-broker-dispatcher和kafka-webhook-eventing几个应用相关的Deployment。namespaceDefaults配置段，指定了在event-demo这一特定的名称空间上使用Kafka作为默认的Broker类别；首先,部署Kafka Broker相关的Kafka Controller。部署KafkaBroker。

Kafka是一个分布式流式数据平台，它具有三个关键特性。

ImporterChannel支持多路订阅为订阅者“持久化”消息数据Service接收CloudEvents（可选）回复处理后的数据。

关于ChannelEventing中的Channel CRD负责定义名称空间级别的消息总线它的后端要基于特定的实现，如In-Memory Channel（简称imc）、NATS Channel或Kafka Channel等每个Channel应该对应于一个特定Topic通常，Channels and Subscriptions消息投递模式中才需要自行创建Channel关于Subscription。

示例环境中，GitLab无法通过GitLabSource外部地址访问到它，因而，这里可以将其编辑为内部格式的地址，方法是，将域名后缀修example.com修改为svc.cluster.local。通过“测试”，手动推送测试事件即可完成测试，下面是从event-display上获取到的两个不同类型的事件。GitLabSource为指定的事件类型创建一个Webhook，监听传入的事件，并将其传递给消费者。GitLabSource资源创建完成生，会有相应代码仓库Webhook上自动完成注册。

最为简单的Event发送示例Source：curl命令，基于HTTP消息映射规范手动编制消息及事件内容Sink：基于能够接收、解析事件，并将其存入日志的event_display应用为例来模拟事件处理步骤将event_display运行为KService，并为其创建外部域名映射（非必须，使用的话还依赖外部名称解析服务）发起请求测试，并通过event_display验证日志中的事件。

单体架构基于库调用模式开发的大型软件系统中，随着代码模块及代码库的膨胀，程序的执行路径将不可避免地“迷宫化”，直至难以维护；微服务架构建立在HTTP RESTful/RPC之上的微服务架构，借助于迫使开发人员针对远程服务的接口进行编程，克服了程序内部调用路径不可维护这一潜在问题；代价是，不得不在服务间维护复杂的依赖关系，因而执行路径依然存在；微服务架构确实大大降低了单个团队需要管理的代码量，只不过，这是通过将一些责任转移给了其他服务实现的；程序与程序之间需要高度规范的接口契约；事件驱动架构。

是在程序和程序之间实现高速、异步、可靠传递消息的技术程序彼此之间通过互相发送称为message的数据包进行通信通道（Channel）也称为队列（Queue），是连接程序和Channel的的特性类似于消息的集合或数组，但它可以在多台计算机之间共享，并且可以由多个应用程序同时使用发送者（sender）或生产者（producer）是通过将消息写入通道来发送消息的程序接收者（receiver）或消费者（consumer）是通过从通道读取（和删除）消息来接收消息的程序。

初始规模：创建Revision，需要立即初始创建的实例数，满足该条件后Revision才能Ready，默认值为1；缩容时间窗口的存在，也会使得Revision缩容的时间有了一定的延迟，这可以在一定程度上减少冷启动的次数。缩容延迟：时间窗口，在应用缩容决策前，该时间窗口内并发请求必须处于递减状态，取值范围[0s, 1h]将上面示例中的配置创建于集群上，即可通过压测工具检验其自动扩展效果。配置支持Revision自动缩放至0实例的参数。硬限制：不允许超出，达到上限的请求需进行缓冲。Target目标利用率。

请求驱动计算”是Serverless的核心特性缩容至0：即没有请求时，系统不会分配资源给KService从0开始扩容：由Activator缓存请求，并报告指标数据给AutoScaler按需扩容：AutoScaler根据Revision中各实例的QP报告的指标数据不断调整Revision中的实例数量Knative系统中，AutoScaler、Activator和Queue-Proxy三者协同管理应用规模与流量规模的匹配Knative附带了开箱即用的AutoScaler，简称为KPA。

修改KService流量策略的途径命令行命令：kn service update --traffic revisionRef=percent引用revision的方法：revisionName、Tag，以及使用“@latest”引用最新的就绪版本“–traffic”选项可以多次使用，直到全部的流量比例之和为100%在KService的资源配置上，使用spec.traffic进行定义为目标KService创建自定义的Route资源，为其配置临时流量策略命令式命令配置示例。

Serving的工作模式，上图从一个更大的全景图上了解Serving以及它与istio进行结合的时候它们的工作逻辑，Serving有4个关键组件，最关键的组件就是kservice，kservice本身会有两个非常重要的组件组成，一个叫做configuration也就是对应的service的相关配置，第二个是route，service会自动根据用户所指的的service配置来生成route，而根据指指定的configuration的配置以及它当前的状态来为其生成一个不可变快照称作revision，只要conf

示例环境networking layer它是能够帮助kservice来接入流量去负责实现底层route资源关键位置所在可用部署方式。

Kubernetes-based platform to deploy and manage modern serverless workloads. Knative是什么，这是基于kubernetes用于去部署和管理现在severless应用或者serverless工作负载的平台，它是一个severless的平台而非是serverless的实现，完全可以基于knative来运行serverless化的或者是基于knative接口所定义的各式各样的无状态应用，如果借助于它的Eventing接口的话或者是事件

这是今天要讲到的在绑定环节一个重要实现叫Knative，Knative话题与过去所了解到的Serverless当中比如FaaS至少是亚马逊带给我们这样一个观念还是有一定区别的，这一次课程给大家着重介绍一下Knative是如何解决或者在哪些环节上解决了分布式应用场景当中绑定的问题，Knative本身是专注于Serverless的，但是它并非是一个FaaS的实现，FaaS叫做函数即服务也有人把它翻译成叫做功能即服务Function as a Service，亚马逊时代所谓Serverless这个概念被大炒热炒的

单网格集群模型网络模型控制平面模型多网格租用模型。

方法1：Ingress TLS passthrough，JWT Validation at Sidecars工作流程优点缺点方法2：由Ingress Gateway完成OIDC工作流有两种常用的方法工作流程优点缺点方法3：组合JWT和oauth2-proxy自动化OIDC要点工作流程。

Istio的授权机制为Istio网格中的workload提供了mesh-level、namespace-level和workload-level的访问控制机制，它提供如下特性。

Request Authentication Policy会验证JSON Web Token（JWT）中几个关键字段的值请求中token所处的位置Issuer或者请求公共的JWKSIstio检查token的方法若请求报文针对request authentication policy中的rules提供了token，Istio将会核验这些token，并会拒绝无效的token；但Istio默认会接受那些并未提供token的请求；若需要拒绝该类请求，则要通过相应的“授权”规则完成，由这类规则负责完成针对特定操作的限

Peer Authentication Policy负责为工作负载指定其作为服务器端时实施TLS通信的方式，它支持如下模式PERMISSIVE：工作负载支持mTLS流量和纯文本（明文）流量，通常仅应该于将应用迁移至网格过程中的过渡期间使用；STRICT：工作负载仅支持mTLS流量；DISABLE：禁用mTLS；UNSET：从上级继承认证策略的设定；

Istio有着健壮的身份标识、强大的策略机制、透明的TLS加密以及AAA（认证、授权和审计）工具保护网格中的服务和数据；Istio的安全目标默认的安全机制：基础设施及应用程序无须做出任何更改；深度防御体系：集成现成的安全系统来提供多层防御能力；“零信任”网络：在假设底层通信网络完全不受信任的基础构建安全解决方案。

若添加了新的自定义维度（即那些不在默认的可以维度标签列表中） ，则需要在工作负载上显式地启用这些维度才能最终生效；注意：若非必须，不建议在网格级别设定启用方式有两种在特定的工作负载上启用。

Istio默认启用的服务级指标，是在首次部署Istio时由通过自动创建的EnvoyFilter资源定义的这些EnvoyFilter资源定义在网格名称空间（例如istio-system）下获取命令：~$ kubectl get envoyfilters -n istio-system以envoyfiler/stats-filter-1.12资源为例，右侧是配置片断该EnvoyFilter用于配置名为envoy.wasm.stats的过滤器各指标为自动添加一个istio前缀。

策略和可观测性概述策略：速率限制、黑白名单、标头重写及重定向可观测性：指标、日志和分布式跟踪MixerTemplate和AdapterAttribute和Attrubue ExpressionMixer的配置模型：Handler、Instance和RuleHandler配置格式及示例Instance配置格式及常用的TemplateMetricLogEntryQuotaRule配置格式及示例。

istio的功能及其实现的相关组件有哪些，istio对如下功能实现了开箱即用就是OOTB的功能，如果配置服务发现和负载均衡的话只需要使用ServicEntry + DestinationRule；要想实现安全的服务到服务之间的加密通信尤其是双向TLS的话DestinationRule就能做到；流量治理当中的关键功能流量控制、流量整形、流量迁移等等都要使用VirtualService来定义；

8.1.6 ServiceEntry使用案例为了便于测试，我们用非网格化的名称空间中运行的应用来模拟运行于VM/裸服务上的外部服务，假设