Paas助理级技能认证

昕昕旺

已于 2023-11-16 10:26:14 修改

阅读量302

点赞数 5

分类专栏：知识总结文章标签： paas 云原生云计算

于 2023-09-18 20:53:43 首次发布

本文链接：https://blog.csdn.net/qq_43939954/article/details/132996232

版权

知识总结专栏收录该内容

3 篇文章 0 订阅

订阅专栏

Paas助理级技能认证

一、云原生基础概念

1.1 了解云原生发展史和基本概念

发展史：

早期物理服务器阶段：在云计算技术演进的早期，核心单元是物理服务器。
虚拟机阶段：后来，随着技术的发展，核心单元逐渐变成了虚拟机。
容器化阶段：当前，随着Kubernetes等容器编排技术的发展，通过Kubernetes编排调度的容器成为了核心单元。在这个阶段，资源的分配颗粒度越来越小，启动速度也越来越快，资源重建的代价越来越小，不可变基础设施逐渐成为主流。

基本概念：

容器化：容器化是将应用程序及其所有依赖项封装到一个独立的容器中的过程。这些容器是轻量级的、可移植的，可以在任何支持容器技术的环境中运行，确保一致性和可重复性。
微服务架构：云原生应用程序通常采用微服务架构，将应用程序拆分为小的、独立的服务单元。每个微服务都可以独立部署、扩展和维护，从而提高灵活性和可维护性。
自动化：云原生应用程序强调自动化，包括自动部署、自动扩展、自动监控和自动修复等。这些自动化任务可以通过工具和编排系统来实现，减少了人工干预的需求。
持续交付：云原生开发实践通常包括持续集成和持续交付，使开发团队能够频繁地发布新的功能和更新，同时保持应用程序的稳定性。
服务网络：服务网格是一种网络基础设施，用于管理微服务之间的通信、安全性和可观察性。它可以提供流量控制、故障恢复和监控等功能。
云原生安全：云原生应用程序需要采用安全最佳实践，包括容器安全、身份认证和访问控制，以确保应用程序和数据的安全性。
多云策略：云原生方法支持在多个云服务提供商之间部署应用程序，以减轻锁定厂商的风险，并提供更高的可用性和容错性

总之，云原生是一种现代化的软件开发和部署方法，旨在充分利用云计算和容器化技术，以构建具有高可伸缩性、高弹性和高可维护性的应用程序。它涵盖了多个概念和实践，旨在帮助开发团队更快地交付高质量的软件，并更好地适应不断变化的市场需求。

1.2 了解云原生技术范畴

容器化技术：容器化技术是云原生的基础，它允许应用程序及其依赖项被打包到独立的容器中。一些常见的容器化技术包括：
1. Docker：最流行的容器技术，用于创建、分发和运行容器。
2. Containerd：一个用于管理容器的开源守护程序。
3. rkt（Rocket）：另一种容器运行时，提供了容器隔离和安全性。
容器编排和管理：容器编排工具用于自动化容器的部署、扩展和管理。一些常见的容器编排工具包括：
1. Kubernetes：一个开源的容器编排平台，用于自动化应用程序的部署和运维。
2. Docker Swarm：Docker的原生编排工具，用于管理Docker容器集群。
3. Apache Mesos：用于集群管理和资源分配的开源平台。
微服务架构：微服务是云原生应用程序的核心构建块，微服务架构涉及到将应用程序拆分为小的、独立的服务单元。一些与微服务相关的技术包括：
1. Service Discovery：用于发现和管理微服务的位置和状态。
2. API Gateway：用于管理和公开微服务的API。
3. Circuit Breaker模式：用于处理微服务之间的故障和超时。
自动化集成/持续交付：自动化工具和流程是云原生开发的关键。这些包括：
1. Jenkins：用于自动化构建、测试和部署的开源工具。
2. Travis CI：云原生环境中的持续集成工具。
3. CircleCI：用于自动化部署的持续集成工具。
日志和监控：了解应用程序的运行状况对于云原生环境至关重要。相关技术包括：
1. Prometheus：用于监控和警报的开源工具。
2. ELK Stack（Elasticsearch、Logstash、Kibana）：用于日志收集、分析和可视化的工具集。
3. Grafana：用于创建仪表板和可视化监控数据的工具。
服务网格和代理：服务网格是用于管理微服务之间通信的网络层，代理用于控制流量和提供安全性。相关技术包括：
1. Istio：一个流行的开源服务网格，用于控制、保护和连接微服务。
2. Envoy：一个用于负载均衡和代理的高性能开源代理。
安全性和身份认证：云原生应用程序需要采取安全措施，确保数据和通信的保密性和完整性。相关技术包括：
1. OAuth 2.0：用于身份认证和授权的协议。
2. JWT（JSON Web Tokens）：用于令牌验证和身份验证的标准。
3. RBAC（Role-Based Access Control）：用于访问控制的策略。
多云和混云管理：为了提高可用性和灵活性，许多组织使用多个云提供商或混合云环境。相关技术包括多云管理平台和工具，用于统一管理多个云环境。

总之，云原生技术范畴包括了一系列用于构建、部署和管理现代化、可扩展和弹性的应用程序所需的技术和工具。这些技术和工具共同帮助组织更好地适应云计算环境，加速软件交付，并提高应用程序的可用性和可维护性。

1.3 了解云原生相关核心技术架构

1.4 了解云原生功能概览

二、云原生核心技术

2.1 了解容器基本概念和发展历程

2.2 熟悉Docker概念、核心功能及应用场景

2.3 了解Docker核心技术及基础使用

2.4 熟悉k8s和容器编排理念

2.5 了解k8s核心架构和关键组件

2.6 熟悉k8s运用场景及核心价值

Kubernetes（通常称为K8s）是一个强大的容器编排平台，可以用于管理和编排容器化应用程序。它在各种运用场景中提供了核心价值，下面详细讲解Kubernetes的运用场景及其核心价值：

1. 容器编排和自动化部署：

         场景：Kubernetes最初被开发为容器编排工具，用于自动化部署、扩展和管理容器化应用程序。它适用于微服务架构，允许将应用程序拆分为小型服务，每个服务都可以打包为一个容器。

         核心价值：Kubernetes可以自动化地将容器化应用程序部署到集群中的多个节点，根据资源需求动态调整容器的数量，并处理节点故障时的容错和自动恢复。这提供了高度的可用性、弹性和可扩展性。

2. 负载均衡和服务发现：

         场景：Kubernetes提供了Service资源，用于定义一组Pod的网络终结点，自动创建负载均衡器，使外部和内部流量能够轻松访问应用程序。

         核心价值：Kubernetes的负载均衡和服务发现功能允许应用程序自动扩展，而无需手动配置负载均衡规则。它还支持DNS解析，使应用程序可以通过服务名称而不是IP地址来访问其他服务，从而简化了服务之间的通信。

3. 滚动升级和回滚：

         场景：Kubernetes的Deployment资源允许用户定义应用程序的部署和升级策略。这意味着您可以无缝地进行滚动升级，同时确保不中断正在运行的应用程序。

         核心价值：Kubernetes提供了滚动升级和回滚功能，使应用程序可以在更新时保持可用性。您可以定义升级的最小和最大Pod数量，以及升级的速率，从而控制升级的流量。如果升级出现问题，您可以快速回滚到之前的版本。

4. 多环境和多租户管理：

         场景：Kubernetes支持多环境和多租户部署，允许在同一集群中运行多个应用程序、团队或环境，同时保持隔离。

         核心价值：通过使用命名空间和RBAC（基于角色的访问控制），Kubernetes可以实现多租户和多环境隔离。这样，不同的团队可以在同一集群中独立管理和部署其应用程序，同时共享底层的硬件资源。

5. 弹性伸缩和资源管理：

         场景：Kubernetes可以根据负载和资源需求自动扩展和收缩容器实例，以确保应用程序具有所需的计算资源。

         核心价值：Kubernetes的自动扩展功能允许您根据流量和资源使用情况自动调整应用程序的规模，以满足高峰时段的需求，同时在低峰时节省资源成本。这提供了资源效率和成本控制的核心价值。

6. 多云和混合云部署：

         场景：Kubernetes支持在不同的云提供商之间和本地数据中心中部署容器应用程序，实现多云和混合云策略。

         核心价值：Kubernetes的跨云和混合云部署能力允许组织在不同的云环境中运行应用程序，同时使用相同的Kubernetes工具和管理方法，减少了云锁定问题，提供了更大的灵活性和选择性。

总之，Kubernetes在容器化应用程序的管理和运维中提供了许多核心价值，包括自动化部署、负载均衡、滚动升级、多环境管理、弹性伸缩和多云支持。这些价值使Kubernetes成为现代应用程序部署和管理的关键工具，有助于提高应用程序的可用性、可扩展性和资源效率。

三、Pass平台通用能力

3.1 熟悉链路追踪Skywalking基础概念、核心组件和基础操作

1. 基础概念

         链路追踪：链路追踪是指跟踪分布式系统中一次请求的完整路径，包括请求进入系统、经过不同组件和服务、最终响应返回客户端的过程。SkyWalking通过链路追踪记录这些路径，以便分析性能问题。

         服务：服务是分布式系统中的一个组件或模块，可以是一个独立的微服务、应用程序的一部分或一个后端服务。

         组件：组件是服务中的具体部分，例如数据库、消息队列、HTTP服务器等。SkyWalking通过识别组件来帮助用户更好地理解系统的构成。

         指标：指标是关于系统性能的定量数据，包括请求响应时间、错误率、吞吐量等。SkyWalking可以收集和展示这些指标。

2. 核心组件

         Collector：Collector是SkyWalking的数据收集器，负责接收来自各个服务的追踪数据和指标，并将其存储在数据存储中，如Elasticsearch、InfluxDB或其他支持的存储后端。

         Storage： Storage负责将收集到的数据持久化存储，以供后续查询和分析。常用的存储后端包括Elasticsearch、InfluxDB、TiDB等。

         UI：Web UI提供了用户界面，用于查询和可视化监控数据，包括链路追踪、指标图表等。

         Agent：Agent是安装在每个服务实例中的代理程序，用于收集应用程序的性能数据和分布式追踪信息，并将其发送给Collector。

         探针(Probe)：探针是SkyWalking的插件系统，用于支持不同的编程语言和框架。每个编程语言或框架都可以使用适当的探针集成到SkyWalking中，以实现性能数据的收集。

3. 基础操作

         部署SkyWalking Collector：首先，在您的环境中部署SkyWalking Collector。您需要选择合适的存储后端，并配置Collector以接收来自Agent的数据。

         安装Agent：在每个服务实例中安装SkyWalking Agent。Agent会自动收集性能数据和追踪信息，并将其发送到Collector。

         配置探针：如果您的应用程序使用了特定的编程语言或框架，您需要配置适当的探针以与SkyWalking集成。

         访问Web UI：通过浏览器访问SkyWalking的Web UI，可以通过界面查询和可视化监控数据。

         创建仪表板：根据您的需求，您可以创建自定义的仪表板，以便更好地监控特定的服务或指标。

         分析链路追踪：使用SkyWalking的链路追踪功能，您可以深入了解请求的路径和性能，以识别潜在的性能问题。

         监控和警报：您可以设置警报规则，以便在性能问题超过阈值时接收通知。

        总之，SkyWalking是一个功能强大的分布式系统性能监测工具，可帮助您监测和分析分布式系统的性能问题，以确保应用程序的稳定性和性能。通过部署Collector、Agent和配置探针，您可以开始使用SkyWalking来监控您的应用程序。

3.2 熟悉Istio和Envoy服务网格概念、核心组件及基本使用

服务网格的基本功能

1. 控制服务间通信：熔断、重试、超时、故障注入、负载均衡和故障转移等；

2. 服务发现：通过专用的服务总线发现服务断点；

3. 可观测：指标数据采集、监控、分布式日志记录和分布式追踪；

4. 安全性：TLS/SSL通信和密钥管理；

5. 身份认证和授权检查：身份认证，以及基于黑名单或RBAC的访问控制功能；

6. 部署：对容器技术的原生支持，例如Docker和Kubernetes等；

7. 服务间的通信协议：HTTP1.1、HTTP2.0和RPC等；

8. 健康状态检测：检测上游服务的健康状态；

.......

服务网格的部署模式：主机共享代理及 Sidecar容器

服务网格的实现方案：Linkerd、Envoy、Istio

Envoy是什么？

Envoy是一个专为大型现代面向服务架构（SOA）设计的L7代理和通信总线。它源于以下理念：网络应该对应用程序透明，当网络和应用程序出现问题时，应该很容易确定问题的来源。Envoy是用C++编写的，具有高度并行和无阻塞的特点。

Envoy的几个显著特性：性能、可扩展性及动态可配置性

性能：除了大量功能外，Envoy还提供极高的吞吐量和低尾延迟差异，同时消耗相对较少的CPU和RAM；
可扩展性：Envoy在L4和L7上提供丰富的可插拔过滤器功能，允许用户轻松添加新功能；
API可配置性：Envoy提供了一组可由控制平面服务实现的管理API，也称为xDS API
        1. 若控制平面实现了这所有的API，则可以使用通用引导配置在整个基础架构中运行Envoy
        2. 所有进一步的配置更改都可通过管理服务器无缝地进行动态传递，使得Envoy永远不需要重新启动
        3. 于是，这使得Envoy成为一个通用数据平面，当与足够复杂的控制平面相结合时，可大大降低整体操作复杂性。
Envoy xDS API存在v1和v2两个版本
        v1 API 仅使用 JSON/REST，本质上是轮询
        v2 API 是 v1 的演进，而不是革命，它是 v1 功能的超集，新的API模式使用 proto3 指定，并同时以 gRPC 和 REST + JSON/YAML 端点实现

Envoy基础组件

xDS API常用术语

1. 集群（Cluster）：集群是Envoy连接到的一组逻辑上相似的端点；在v2中，RDS通过路由指向集群，CDS提供集群配置，而Envoy通过EDS发现集群成员，即端点；
2. 下游（Downstream）：下游主机连接到Envoy，发送请求并接收响应，它们是Envoy的客户端；
3. 上游（Upstream）：上游主机接收来自Envoy的连接和请求并返回响应，它们是Envoy代理的后端服务器；
4. 端点（Endpoint）：端点即上游主机，是一个或多个集群的成员，可通过EDS发现；
5. 侦听器（Listener）：侦听器是能够由下游客户端连接的命名网络位置，例如端口或unix域套接字等；
6. 位置（Locality）：上游端点运行的区域拓扑，包括地域、区域和子区域等；
7. 管理服务器（Management Server）：实现v2 API的服务器，它支持复制和分片，并且能够在不同的物理机器上实现针对不同xDS API的API服务；

8. 地域（Region）：区域所属地理位置；
9. 区域（Zone）：AWS中的可用区（AZ）或GCP中的区域等；
10. 子区域：Envoy实例或端点运行的区域内的位置，用于支持区域内的多个负载均衡目标；
11. xDS：CDS 、EDS、HDS 、LDS、RLS(Rate Limit)、 RDS 、 SDS、VHDS和RTDS等API的统称；

Envoy 部署类型

        Envoy通常用于以容器编排系统为底层环境的服务网格中，并以sidecar的形式与主程序容器运行为单个Pod；非编排系统环境中测试时，可以将主程序与Envoy运行于同一容器，或手动组织主程序容器与Envoy容器共享同一网络名称空间；
        Ingress是指进入集群的流量，而Egress是指离开集群的流量。
        Ingress和Egress的区别在于它们的网络协议和访问方式不同。Ingress通常用于HTTP和HTTPS等应用层协议的流量，而Egress则用于各种传输层协议的流量，例如TCP和UDP等。此外，Ingress通常用于代理和负载均衡服务，而Egress则用于访问外部网络或服务。

Envoy线程模型

Envoy使用单进程/多线程的架构模型，一个主线程（Main thread）负责实现各类管理任务，而一些工作线程（Worker threads）则负责执行监听、过滤和转发
等代理服务器的核心功能。
1. 主线程：负责Envoy程序的启动和关闭、xDS API调用处理（包括DNS、健康状态检测和集群管理等）、运行时配置、统计数据刷新、管理接口维护和其它线程管理（信号和热重启等）等，相关的所有事件均以异步非阻塞模式完成；
2. 工作线程：默认情况下，Envoy根据当前主机CPU核心数来创建等同数量的工作线程，不过，管理员也可以通过程序选项--concurrency具体指定；每个工作线程运行一个非阻塞型事件循环，负责为每个侦听器监听指定的套接字、接收新请求、为每个连接初始一个过滤器栈并处理此连接整个生命周期中的所有事件；
3. 文件刷写线程：Envoy写入的每个文件都有一个专用、独立的阻塞型刷写线程，当工作线程需要写入文件时，数据实际上被移入内存缓冲区，最终通过文件刷写线程同步至文件中。

Envoy 连接处理

Envoy通过侦听器监听套接字并接收客户端请求，而Envoy的所有工作线程会同时共同监听用户配置的所有套接字，对于某次连接请求，由内核负责将其派发至某个具体的工作线程处理; 随后，相关的工作线程基于特定的处理逻辑分别由相关组件依次完成连接管理;

Envoy配置概述

1. 启动时从Bootstrap配置文件中加载初始配置

2. 支持动态配置

        2.1 xDS API

                · 从配置文件加载配置

                · 从管理服务器基于xDS协议加载配置

        2.2 runtime

                · 某些关键特性保存为key/value数据

                · 支持多层配置和覆盖机制

3. 启动全动态配置机制后，仅极少数场景需要重新启动Envoy进程

        3.1 支持热启动

Envoy配置方式

Envoy的架构支持非常灵活的配置方式：简单部署场景可以使用纯静态配置，而更复杂的部署场景则可以逐步添加需要的动态配置机制。

1.1 纯静态配置：用户自行提供侦听器、过滤器链、集群及HTTP路由（http代理场景），上游端点的发现仅可通过DNS服务进行，且配置的重新加载必须通过内置的热重启（hot restart）完成；

1.2 仅使用EDS：EDS提供的端点发现功能可有效规避DNS的限制（响应中的最大记录数等）；

1.3 使用EDS和CDS：CDS能够让Envoy以优雅的方式添加、更新和删除上游集群，于是初始配置时，Envoy无须事先了解所有上游集群；

1.4 EDS、CDS和RDS：动态发现路由配置；RDS与EDS、CDS一起使用时，为用户提供了构建复杂路由拓扑的能力（流量转移、蓝/绿部署等）；

1.5 EDS、CDS、RDS和LDS：动态发现侦听器配置，包括内嵌的过滤器链；启用此四种发现服务后，除了较罕见的配置变动、证书轮替或更新Envoy程序之外，几乎无须再热重启 Envoy；

1.6 EDS、CDS、RDS、LDS和SDS：动态发现侦听器密钥相关的证书、私钥及TLS会话票据，以及对证书验证逻辑的配置（受信任的根证书和撤销机制等）；

Envoy配置中的重要概念

Bootstrap配置中几个重要的基础概念

         node：节点标识，以呈现给管理服务器并且例如用于标识目的；

         static_resources：静态配置的资源，用于配置静态的listener、cluster 和secret；

         dynamic_resources：动态配置的资源，用于配置基于xDS API获取 listener、cluster和secret配置的lds_config、cds_config和ads_config；

         admin：Envoy内置的管理接口；

         tracing：分布式跟踪；

         layered_runtime：层级化的运行时，支持使用RTDS从管理服务器动态加载；

         hds_config：使用HDS从管理服务器加载上游主机健康状态检测相关的配置；

         overload_manager：过载管理器；

         stats_sinks：统计信息接收器；

一般来说，侦听器和集群是最为常用基础配置，无论是以静态或者是动态方式提供；

侦听器和集群配置概述

侦听器

         接收客户端请求的入口端点，通常由监听的套接字及调用的过滤器链所定义

         代理类的过滤器负责路由请求，例如tcp_proxy和http_connection_manager等

         目前，Envoy仅支持TCP侦听器

         独立部署时，建议每个主机仅部署单个Envoy实例，并在必要时于此实例上运行一到多个侦听器

集群

         一组上游主机的逻辑组合

         每个主机映射为集群中的一个端点

         下游的请求被调度至上游主机

Istio是什么？

Istio是Envoy Data Plane的控制平面实现之一

Istio是一个开源的独立服务网格，可为用户成功运行分布式微服务架构提供所需的基础设施

Istio v1.0 时代

控制平面主要有三个组件

         Pilot：控制平台核心组件

1. 管理和配置部署在Istio服务网格中的所有Envoy代理实例

2. 为Envoy Sidecar提供服务发现、智能路由的流量管理功能（例如：A/B测试、金丝雀推出等和弹性：超时、重试、断路器等）

         Citadel：身份和凭证管理等安全相关的功能，实现强大的服务到最终用户身份验证。

         Mixer：遥测和策略(管理授权和审计)（V1.5后遥测功能由Envoy管理）

1.1 通过内部插件接口扩展支持第三方组件

1.2 插件的修改和更新，需要重新部署Mixer

数据平面Envoy

         基于sidecar模式同网格的每个服务实例一同部署。

         拦截服务流量，强制执行控制平面中定义的策略，并收集遥测数据。

Istio v1.1 时代

Mixer

         将插件模型替换为使用进程外的Adapter进行扩展（性能表现更差）

         完成了Mixer与扩展间的解耦

Galley

         Galley负责向Istio控制平面的其它组件提供支撑功能

         从实现上来说，Galley通过Kubernetes的动态Admission Controller（Admission Hook ）完成组件配置的校验

         Pilot中适配底层平台的功能独立成的组件

         是Istio的配置验证、摄取、处理和分发组件

         负责将其余的Istio组件从底层平台（如：k8s）获取用户配置的细节隔离开来，从而将Pilot与底层平台进行解耦

Istio v1.5 时代

回归单体

         抛弃影响性的Mixer，遥测功能交由Envoy自行完成。

         将Pilot、Citadel、Galley和Sidecar Injectore整合成一个单体应用Istio

1.1 Istio服务网格中的每个Pod都必须伴随一个Istio兼容的Sidecar一同运行，常用的将 Sidecar注入Pod中的方法有两种

                         手工注入：使用istioctl客户端工具进行注入

                         自动注入：使用Istio sidecar injector自动完成注入过程

Istiod

         Istiod充当控制平面，将配置分发到所有的Sidecar代理和网关

         它能够为支持网络的应用实现智能化的负载均衡机制，且相关流量绕过了kube-proxt

3.3 熟悉Istio服务网格的Telemetry API与可观性概念及基本使用

Mech Service 服务网格。是一个基础设施层，让服务之间的通信更安全、快速和可靠。如果你在构建云原生应用，那么就需要 Service Mesh。

EnvoyFilter

1. EnvoyFilter CR提供了自定义Sidecar Envoy配置的接口，其支持的配置功能包括修改指定字段的值、添加特定的过滤器甚至是新增Listener和Cluster等

2. 常在Istio原生的各CR未能提供足够的配置机制，或者无法支持到的配置场景中使用。

3. 同Sidecar等其它几个位于同一API群组内的CR不同的是：EnvoyFilter CR资源对象对自适应的方式应用于workload上

注意事项：

1. 对于不同的Istio发行版来说，EnvoyFilter提供的配置可能不具有向后兼容性；

2. Istio Proxy版本升级时，需要仔细识别配置字段的废弃和添加等所产生的影响；

3. 多个EnvoyFilter资源对象应用于同一个workload时，它们会根据创建时依次生效，而配置冲突时其结果将无从预料；

4. 切记要谨慎使用该功能，不当的配置定义，可能会破坏网络的稳定性；

可观测性

日志、指标和跟踪是应用程序可观测性的三大支柱，前二者更多的是属于传统的“以主机为中心”的模型，而跟踪则“以流程为中心”

1. 日志：日志是随时间发生的离散事件的不可变时间戳记录，对单体应用很有效，但分布式系统的故障通常会由多个不同的组件之间的互连事件触发；

2. 指标：由监控系统时序性收集和记录的固定类型的可聚合数据，同时对单体应用较有效，但无法提供足够的信息来理解分布式系统中调用的生命周期；

3. 跟踪：跟踪是跟随一个事务或一个请求从开始到结束的整体生命周期的过程，包括其所流经的组件；

Istio的可观测性

Istio为网格内所有的服务间通信生成详细的可观测性数据，以便于运维人员排障，维护和优化；

它生成的遥测类型数据包括以下几种：

1. Metrics：服务指标（基于四个黄金信号：延迟、流量、错误和饱和度）和控制平面的详细指标；

· Proxy-level metrics：代理级指标，数据平面指标

· Service-level metrics：服务指标，用于监控服务通信，数据平面指标

· Control plane metrics：控制平面指标

2. Distributed Traces：支持为每个服务生产span，以记录服务依赖和调用关系；

· Istio支持通过代理程序Envoy进行分布式追踪

· 这意味着被代理的应用程序只需要转发适当的context即可，实现了“近零侵入”

· 支持Zipkin、Jaeger、LightStep和Datadog等后端系统

· 支持运维人员自定义采样频率

3. Access Log：可于workload级别为每个服务请求生成完整的记录，包括源和元数据；

Istio的可观测性（2）

1. Istio的可观测性功能主要发生在网格中的数据平面上

· 因为数据平面代理Istio-proxy（Envoy）位于服务间的请求路径上

· Istio需要通过Envoy捕获与请求处理和服务交互相关的重要指标

· Istio还附带了一些OOTB工具，例如Prometheus、Grafana和Kiali等

2. Istio在网格代理上启用的可观测性机制，可以在部署Istio时进行配置，也可随后通过MeshConfig或者Telemetry CR定义

v1主动收集指标

v2被动收集指标

服务级指标由两个自定义的Envoy插件实现：1. metadata-exchange 2. stats

3.3 Istio快速实践

实例集群及项目基础组件

部署Istio控制平面

部署方法

1. istioctl

 istio的专用管理工具、支持定制控制平面及数据平面

 通过命令行的选择支持完整的IstioOperator API

 命令行各选择可用于单独设置、以及接收包含IstioOperator自定义资源的yaml文件

2. Istio Operator

                 Istio相关的自定义资源（CR）的专用控制器，负责自动维护由CR定义的资源对象

                 管理员根据需要定义响应的CR配置文件，提交后，即可由Operator完成相应的操作

3. helm

                基于特定的Chart，亦可由Helm安装及配置Istio

 截至目前，该功能处于alpha阶段

提示

1. 各部署工具依赖的前提条件有所不同，使用前，需要按其实际需求做准备工作

2. 各工具的部署操作，最总都要转换为K8s的资源配置文件，并创建于集群上

使用istioctl快速部署istio 1.4

前提：准备好kubernetes集群

下载程序

         下载istioctl及相关的安装文件和示例文件

                 $ cd /usr/local

                 $ curl -L https://istio.io/downloadIstio | sh -

                 $ ln -sv istio-1.4.0 istio

         切换工作目录为istio的下载目录

                 $ cd istio 安装目录包含部署于kubernetes相关的YAML配置文件“install/kubernetes”，示例程序目录 samples/和相关的客户端程序文件

         添加istioctl程序文件所在的目录至PATH环境变量

                 export PATH=/usr/local/istio/bin:$PATH

istioctl提供了内置配置文件用于快速部署

         default：根据IstioControlPlanAPI的默认设置启用相关的组件，适用于生产环境；

         demo：旨在演示istio的功能，适合运行 Bookinfo一类的应用程序

         minimal：使用Istio流量管理功能所需要的最小化部署

         sds：类似于default配置，但额外启用了SDS

         remote：用于配置共享Control Plane的多集群环境

部署Istio

         基于demo配置进行部署测试

                 $ istioctl manifest apply --set profile=demo

         验证相关的Pod和Service已经成功部署

         $ kubectl get pods -n istio-system

         $ kubectl get svc -n istio-system