探索 Kubernetes 服务网格：Istio 实战指南

月下独码

于 2024-09-16 00:15:00 发布

阅读量888

点赞数 22

分类专栏： Kubernetes 文章标签： kubernetes istio 容器云原生

本文链接：https://blog.csdn.net/lilinhai548/article/details/142204362

版权

Kubernetes 专栏收录该内容

12 篇文章 2 订阅

订阅专栏

🧑 博主简介：历代文学网（PC端可以访问：https://literature.sinhy.com/#/literature?__c=1000，移动端可微信小程序搜索“历代文学”）总架构师，15年工作经验，精通Java编程，高并发设计，Springboot和微服务，熟悉Linux，ESXI虚拟化以及云原生Docker和K8s，热衷于探索科技的边界，并将理论知识转化为实际应用。保持对新技术的好奇心，乐于分享所学，希望通过我的实践经历和见解，启发他人的创新思维。在这里，我希望能与志同道合的朋友交流探讨，共同进步，一起在技术的世界里不断学习成长。

在这里插入图片描述

摘要

随着微服务架构的普及，Kubernetes 已成为现代应用部署的标准平台。然而，管理微服务之间的通信和安全性仍然是一个挑战。本文将深入探讨 Kubernetes 服务网格的核心概念，并通过 Istio 的实战案例，展示如何简化微服务管理，提升应用的可靠性和安全性。

引言

Kubernetes 作为容器编排的领导者，极大地简化了应用的部署和管理。然而，随着微服务数量的增加，服务间的通信、监控和安全性问题变得越来越复杂。服务网格（Service Mesh）应运而生，成为解决这些问题的关键技术。Istio 作为 Kubernetes 生态中最受欢迎的服务网格解决方案之一，提供了强大的流量管理、安全性和可观察性功能。

服务网格的核心概念

1. 什么是服务网格？

服务网格是一个专门的基础设施层，用于处理服务间的通信。它通过在每个服务实例旁边部署一个轻量级的网络代理（Sidecar），来管理服务间的流量、策略和安全性。

Istio 解决了开发人员和运维人员在分布式或微服务架构中面临的挑战。无论您是从头开始构建、将现有应用程序迁移到云原生，还是保护现有资产，Istio 都可以提供帮助。
在这里插入图片描述

服务网格是一个基础设施层，它为应用程序提供零信任安全、可观察性和高级流量管理等功能，而无需更改代码。Istio 是最受欢迎、最强大、最值得信赖的服务网格。 Istio 由 Google、IBM 和 Lyft 于 2016 年创立，是云原生计算基金会的一个毕业项目，与 Kubernetes 和 Prometheus 等项目并列。

Istio 可确保云原生和分布式系统具有弹性，帮助现代企业在保持连接和保护的同时跨不同平台维护其工作负载。它启用安全和治理控制，包括 mTLS 加密、策略管理和访问控制、支持网络功能，例如金丝雀部署、A/B 测试、负载平衡、故障恢复，并增加对整个资产流量的可观察性。

2. 为什么选择 Istio？

Istio 在 2017 年推出时率先提出了基于 Sidecar 的服务网格概念。该项目从一开始就包含了定义服务网格的功能，包括用于零信任网络的基于标准的双向 TLS、智能流量路由以及通过指标、日志和链路追踪实现的可观察性。

从那时起，该项目推动了网格领域的进步，包括多集群和多网络拓扑、通过 WebAssembly 实现可扩展性、 Kubernetes Gateway API 的开发，以及使用 Ambient 模式将网格基础设施从应用程序开发人员手中移开。

以下是我们认为您应该使用 Istio 作为服务网格的几个原因。

2.1 简单而强大

Kubernetes 有数百种功能和数十种 API，但您只需一个命令即可开始使用它。我们构建 Istio 的方式也一样。渐进式公开意味着您可以使用一小部分 API，并且仅在需要时才使用更强大的功能。其他“简单”服务网格花了数年时间才赶上 Istio 在第一天就拥有的功能集。

拥有一个功能而不需要它比需要而没有这项功能更加美好！

2.2 Envoy 代理

从一开始，Istio 就由 Envoy 代理提供支持，这是一个最初由 Lyft 构建的高性能服务代理。Istio 是第一个采用 Envoy 的项目， Istio 团队是第一批外部提交者。 Envoy 后来成为为 Google Cloud 提供支持的负载均衡器以及几乎所有其他服务网格平台的代理。

Istio 继承了 Envoy 的所有功能和灵活性，包括使用 Istio 团队在 Envoy 中开发的实现世界级可扩展性。

2.3 社区

Istio 是一个真正的社区项目。2023 年，有 10 家公司为 Istio 做出了超过 1,000 项贡献，并没有一家公司的贡献超过 25%。（在此处查看数字）。

没有其他服务网格项目像 Istio 一样获得业界如此广泛的支持。

2.4 我有 CNI。为什么我需要 Istio？

如今，一些 CNI 插件开始以附加组件的形式提供类似服务网格的功能，这些附加组件位于其自己的 CNI 实现之上。例如，它们可以为节点或 Pod 之间的流量、工作负载身份实现自己的加密方案，或者通过将流量重定向到 L7 代理来支持一定数量的传输级策略。这些服务网格附加组件是非标准的，因此只能在搭载它们的 CNI 之上工作。它们还提供不同的功能集。例如，在 Wireguard 之上构建的解决方案无法符合 FIPS 标准。

为此，Istio 实现了零信任隧道（ztunnel）组件，该组件使用成熟的行业标准加密协议透明高效地提供此功能。了解有关 ztunnel 的更多信息。

Istio 旨在成为一个服务网格，它提供一致、高度安全、高效且符合标准的服务网格实现，提供一组强大的 L7 策略、与平台无关的工作负载身份，使用业界验证的 mTLS 协议 - 在任何环境、任何 CNI，甚至跨具有不同 CNI 的集群。

3. Istio 的主要组件

Envoy：作为 Sidecar 代理，负责处理服务间的流量。
Pilot：提供服务发现和流量管理功能。
Citadel：负责安全性和身份认证。
Galley：处理配置管理。
Mixer：提供策略和遥测数据收集。

实战案例：使用 Istio 实现金丝雀发布

1. 环境准备

首先，确保你已经安装了 Kubernetes 集群（如果不会搭建K8s集群的朋友，请到右上角专栏选择k8s集群搭建相关文章进行搭建）并部署了 Istio。可以通过以下命令安装 Istio：

curl -L https://istio.io/downloadIstio | sh -
cd istio-<version>
export PATH=$PWD/bin:$PATH
istioctl install --set profile=demo -y

2. 部署示例应用

我们将部署一个简单的微服务应用，包含两个版本（v1 和 v2）。使用以下 YAML 文件部署应用：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
      version: v1
  template:
    metadata:
      labels:
        app: myapp
        version: v1
    spec:
      containers:
      - name: myapp
        image: myapp:v1
        ports:
        - containerPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
      version: v2
  template:
    metadata:
      labels:
        app: myapp
        version: v2
    spec:
      containers:
      - name: myapp
        image: myapp:v2
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

3. 配置 Istio 路由规则

为了实现金丝雀发布，我们需要配置 Istio 的路由规则，将部分流量引导到新版本（v2）。使用以下 YAML 文件创建路由规则：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp-vs
spec:
  hosts:
  - myapp-service
  http:
  - route:
    - destination:
        host: myapp-service
        subset: v1
      weight: 90
    - destination:
        host: myapp-service
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: myapp-dr
spec:
  host: myapp-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2