hugo-teek is loading...

2024-12-25 k8s +2 istio 3、Istio基础 4841 字 21 分钟 -- 次

8、Istio工作负载

最后更新于: 2025-12-06 17:39:04

更新于：2023年12月28日2

Istio工作负载

本节实战

实战名称
🚩 实战：WorkloadEntry测试-2023.12.21(测试成功)

前言

在之前的章节中我们已经多次提到了工作负载，在 Istio 中工作负载是指部署在 Kubernetes 中的应用程序，但是如果我们的工作负载是不在 Kubernetes 集群中（如虚拟机中）那么还能否使用 Istio 呢？答案是肯定的。

Istio 提供了 WorkloadEntry 资源对象，用于将非 Kubernetes 工作负载引入到 Istio 网格中。

WorkloadEntry必须与一个 Istio ServiceEntry一起使用，配合对 ServiceEntry 定义的服务进行服务实例注册。WorkloadEntry 允许我们描述非 Pod 端点，这些端点应该仍然是网格的一部分，并将其与 Pod 同等对待，比如在工作负载之间启用 MUTUAL_TLS，无论它们是否是容器化的。

1、WorkloadEntry

要创建一个 WorkloadEntry 并将其附加到一个 ServiceEntry 上，可以这样实现：

 1apiVersion: networking.istio.io/v1beta1
 2kind: WorkloadEntry
 3metadata:
 4  name: vm1
 5  namespace: ns1
 6spec:
 7  address: 1.1.1.1
 8  labels:
 9    app: foo
10    instance-id: vm-78ad2
11    class: vm
12---
13apiVersion: networking.istio.io/v1beta1
14kind: ServiceEntry
15metadata:
16  name: svc1
17  namespace: ns1
18spec:
19  hosts:
20    - svc1.internal.com
21  ports:
22    - number: 80
23      name: http
24      protocol: HTTP
25  resolution: STATIC
26  workloadSelector: # 工作负载选择器
27    labels:
28      app: foo

这将创建一个带有一组标签和地址的新 WorkloadEntry，以及使用 WorkloadSelector 来选择所有带有所需标签的端点的 ServiceEntry，在这种情况下包括为 VM 创建的 WorkloadEntry。

ServiceEntry 可以同时引用 Pod 和 WorkloadEntry，使用相同的选择器，现在 Istio 可以对 VM 和 Pod 进行相同的处理，而不是将它们分开。如果要将一些工作负载迁移到 Kubernetes，且选择保留大量的 VM，则 WorkloadSelector 可以同时选择 Pod 和 VM，Istio 会自动在它们之间进行负载均衡，现在我们就可以让 VM 和 Pod 共存，而不需要任何配置来将两者连接起来。

🚩 实战：WorkloadEntry测试-2023.12.21(测试成功)

实验环境：(实验软件-无)

1k8s v1.27.6（containerd://1.6.20）（cni：flannel:v0.22.2）
2istio v1.19.3(--set profile=demo)

比如现在我们在虚拟机上面部署一个 whoami 的应用，当然可以使用手动的方式来进行部署，为了方便我们将在 192.168.0.100 这个节点上使用 Docker（或者 Containerd）来部署这个服务，并暴露 8888 端口：

 1# 如果是 docker 则使用 docker
 2$ nerdctl run -d -p 8888:80 --name whoami traefik/whoami:v1.10.1 --verbose
 3
 4$ nerdctl ps
 5CONTAINER ID    IMAGE                               COMMAND                CREATED          STATUS    PORTS                   NAMES
 698cd22ef6d1a    docker.io/traefik/whoami:v1.10.1    "/whoami --verbose"    5 seconds ago    Up        0.0.0.0:8888->80/tcp    whoami
 7
 8[root@master1 ~]#curl http://172.29.9.61:8888
 9Hostname: 8f66c4c3da05
10IP: 127.0.0.1
11IP: ::1
12IP: 10.4.0.2
13IP: fe80::9cbc:94ff:fe9d:7dce
14RemoteAddr: 172.29.9.61:49796
15GET / HTTP/1.1
16Host: 172.29.9.61:8888
17User-Agent: curl/7.29.0
18Accept: */*
19[root@master1 ~]#
20
21##查看日志
22[root@master1 ~]#nerdctl logs -f whoami
232023/12/19 23:58:44 Starting up on port 80
242023/12/20 04:12:30 172.29.9.61:49796 - - [20/Dec/2023:04:12:30 +0000] "GET / HTTP/1.1" - -
25
26##当然，在浏览器里访问也是一样的。
27……

现在如果我们想通过 Istio 来代理这个服务，那么我们需要将这个外部的服务引入到 Istio 网格中。

首先需要创建一个如下所示的 WorkloadEntry 对象：

 1# whoami-we.yaml
 2apiVersion: networking.istio.io/v1beta1
 3kind: WorkloadEntry
 4metadata:
 5  name: whoami-we
 6spec:
 7  address: 172.29.9.61
 8  labels:
 9    app: whoami
10    instance-id: vm1

在上面的 WorkloadEntry 对象中我们指定了 address 和 labels 字段，其中 address 字段指定了我们在虚拟机上面的服务地址，labels 字段指定了我们的服务的标签，这些标签可以用于 ServiceEntry 对象中的 workloadSelector 字段，这样就可以将 ServiceEntry 和 WorkloadEntry 关联起来了。

然后再创建一个如下所示的 ServiceEntry 对象：

 1# whoami-se.yaml
 2apiVersion: networking.istio.io/v1beta1
 3kind: ServiceEntry
 4metadata:
 5  name: whoami-se
 6spec:
 7  hosts:
 8    - whoami.internal.com # 这里的域名可以自定义
 9  ports:
10    - number: 80
11      name: http
12      protocol: HTTP
13      targetPort: 8888 # 注意这里的端口要和上面的端口一致
14  location: MESH_INTERNAL
15  resolution: STATIC # 静态解析
16  workloadSelector:
17    labels:
18      app: whoami

上面的 ServiceEntry 对象中我们指定了 hosts 字段，这个字段指定了我们的服务的域名，这个域名可以自定义，但是要保证这个域名在网格中是唯一的。然后我们还指定了 ports 字段，这个字段指定了我们的服务的端口，里面的 targetPort 端口要和我们在 WorkloadEntry 中指定的端口一致。然后最重要的是指定 workloadSelector 字段，这个字段指定了我们的服务的标签，这些标签可以用于 WorkloadEntry 对象中的 labels 字段，这样就可以将 ServiceEntry 和 WorkloadEntry 关联起来了。

另外需要注意其中有一个 location 字段，这个字段指定了服务是属于 Istio 网格之内还是网格之外，位置决定了一些功能的行为，例如服务之间的 mTLS 身份验证、策略执行等。当与网格之外的服务通信时，Istio 的 mTLS 身份验证被禁用，并且策略执行是在客户端而不是服务器端执行的，可以配置的值有两个：

MESH_EXTERNAL：表示该服务位于网格外部，通常用于指示通过 API 使用的外部服务。
MESH_INTERNAL：表示该服务是网格的一部分，常用于指示在扩展服务网格以包含非托管基础设施时显式添加的服务（例如，添加到基于 Kubernetes 的服务网格的虚拟机）。

我们这里是要将服务引入到 Istio 网络中来所以使用 MESH_INTERNAL。

然后再创建一个如下所示的 VirtualService 和 Gateway 对象：

 1# whoami-istio.yaml
 2apiVersion: networking.istio.io/v1beta1
 3kind: Gateway
 4metadata:
 5  name: whoami-gw
 6spec:
 7  selector:
 8    istio: ingressgateway
 9  servers:
10    - port:
11        number: 8080
12        name: http
13        protocol: HTTP
14      hosts:
15        - whoami.internal.com
16---
17apiVersion: networking.istio.io/v1beta1
18kind: VirtualService
19metadata:
20  name: whoami-vs
21spec:
22  hosts:
23    - whoami.internal.com
24  gateways:
25    - whoami-gw
26  http:
27    - route:
28        - destination:
29            host: whoami.internal.com
30            port:
31              number: 80
32---
33apiVersion: networking.istio.io/v1beta1
34kind: DestinationRule
35metadata:
36  name: whoami-dr
37spec:
38  host: whoami.internal.com
39  trafficPolicy:
40    loadBalancer:
41      simple: ROUND_ROBIN

直接应用上面的资源对象即可：

 1##部署
 2kubectl apply -f whoami-we.yaml
 3kubectl apply -f whoami-se.yaml
 4kubectl apply -f whoami-istio.yaml
 5
 6##查看
 7[root@master1 WorkloadEntry]#kubectl get workloadentry
 8NAME        AGE   ADDRESS
 9whoami-we   10s   192.168.0.100
10[root@master1 WorkloadEntry]#kubectl get serviceentry
11NAME        HOSTS                     LOCATION        RESOLUTION   AGE
12whoami-se   ["whoami.internal.com"]   MESH_INTERNAL   STATIC       17s
13
14
15[root@master1 ~]#kubectl get gateway
16NAME               AGE
17bookinfo-gateway   2d1h
18httpbin-gateway    4d10h
19whoami-gw          3m1s
20[root@master1 ~]#kubectl get vs
21NAME        GATEWAYS               HOSTS                     AGE
22bookinfo    ["bookinfo-gateway"]   ["*"]                     2d1h
23httpbin     ["httpbin-gateway"]    ["*"]                     4d10h
24whoami-vs   ["whoami-gw"]          ["whoami.internal.com"]   3m20s
25[root@master1 ~]#kubectl get dr
26NAME        HOST                  AGE
27whoami-dr   whoami.internal.com   3m41s
28[root@master1 ~]#

然后我们就可以访问 whoami.internal.com 来验证是否可以正常访问了，也可以通过查看 whoami 的日志来验证是否可以正常访问：

1$ nerdctl logs -f whoami
22023/12/15 05:35:37 Starting up on port 80
32023/12/15 05:35:54 192.168.0.100:54958 - - [15/Dec/2023:05:35:54 +0000] "GET / HTTP/1.1" - -

记得将 whoami.internal.com 解析到 Istio Ingress Gateway 的 IP 地址。

 1[root@master1 ~]#kubectl get po -nistio-system -owide -l app=istio-ingressgateway
 2NAME                                   READY   STATUS    RESTARTS   AGE   IP            NODE    NOMINATED NODE   READINESS GATES
 3istio-ingressgateway-9c8b9b586-5nx58   1/1     Running   0          15m   10.244.2.28   node2   <none>           <none>
 4
 5[root@master1 ~]#kubectl get svc  -nistio-system -l app=istio-ingressgateway
 6NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                                                                      AGE
 7istio-ingressgateway   LoadBalancer   10.105.233.167   <pending>     15021:31410/TCP,80:31666/TCP,443:32213/TCP,31400:30291/TCP,15443:31787/TCP   43d
 8
 9##host映射
10172.29.9.63 whoami.internal.com

从上面的结果可以看到我们的服务已经成功引入到 Istio 网格中了。测试结束。😘

同样我们还可以在 Kubernetes 集群中这个 whoami 工作负载，由于前面我们在 ServiceEntry 中通过 workloadSelector 指定了 app: whoami 标签，所以只要保证我们的工作负载具有这个标签即可。

比如我们创建一个如下所示的 Deployment 对象：

 1# whoami-deploy.yaml
 2apiVersion: apps/v1
 3kind: Deployment
 4metadata:
 5  name: whoami
 6spec:
 7  selector:
 8    matchLabels:
 9      app: whoami
10  template:
11    metadata:
12      labels:
13        app: whoami
14    spec:
15      containers:
16        - name: whoami
17          image: traefik/whoami:v1.10.1
18          command:
19            - --verbose # 打印详细日志
20            - --port=8888 # 指定端口，匹配我们在 ServiceEntry 中指定的端口
21          ports:
22            - containerPort: 8888

直接创建上面的资源对象即可：

1# 记得要注入 sidecar，我们这里 default 命名空间的自动注入是开启的。（为什么要注入sideacar呢？？？😥）
2
3$ kubectl apply -f whoami-deploy.yaml
4$ kubectl get pods -l app=whoami
5NAME                      READY   STATUS    RESTARTS   AGE
6whoami-5c685456d6-8cskw   2/2     Running   0          5m27s

部署完成后，我们再次访问 whoami.internal.com，可以看到请求会在 Kubernetes 集群中的 Pod 和虚拟机中的工作负载之间进行负载均衡请求。

🔱：注意

奇怪：我这里k8s的pod创建失败了，报如下错误？

nerdctl命令创建的容器都是可以运行的哇：

1[root@master1 WorkloadEntry]#nerdctl ps
2CONTAINER ID    IMAGE                               COMMAND                CREATED         STATUS    PORTS                   NAMES
38f66c4c3da05    docker.io/traefik/whoami:v1.10.1    "/whoami --verbose"    22 hours ago    Up        0.0.0.0:8888->80/tcp    whoami

难道是端口问题？？？–（没错呀。。。估计是文档哪里出现问题了。。。）

🔰 注意：以上问题可以用如下方式解决

command换成args 。
自己本次未实际测试，这里仅做记录！！！（2023年12月28日）

🔰 那么问题来了：

k8s的deployment资源对象下container里使用command和使用args有啥区别吗？

在Kubernetes的Deployment资源对象中，container字段用于定义Pod中的容器。在这个container字段中，你可以使用command和args字段来配置容器的启动命令和参数。这两者之间有一些区别：

command字段：
- command字段用于指定在容器启动时执行的命令。
- 如果在command字段中提供了一个非空的命令列表，Kubernetes将仅执行该命令，而不会启动默认的应用程序。
- 该命令将覆盖容器映像中定义的任何默认命令。
例如：
```
1yamlcontainers:
2  - name: my-container
3    image: my-image
4    command: ["echo", "Hello"]
```
上面的例子中，容器将执行echo Hello命令。
args字段：
- args字段用于指定在容器启动时传递给容器中的命令的参数。
- 它允许你在容器启动时传递额外的参数给容器中运行的应用程序。
例如：
```
1yamlcontainers:
2  - name: my-container
3    image: my-image
4    command: ["echo"]
5    args: ["Hello"]
```
上面的例子中，容器将执行echo Hello命令，与上面的command示例相同。

总的来说，command字段用于指定容器的启动命令，而args字段用于向该命令传递参数。你可以根据需要选择使用它们中的一个或两者结合使用。

多实例

在 Kubernetes 中一个服务可以有多个实例，同样对于一个 ServiceEntry 当然也可以关联多个 WorkloadEntry，每个实例还可以使用标签标识实例的版本。

这个小部分没做测试哦，只记录。

比如我们可以创建一个如下所示的 WorkloadEntry 对象：

 1apiVersion: networking.istio.io/v1beta1
 2kind: WorkloadEntry
 3metadata:
 4  name: test1-we
 5spec:
 6  address: 192.168.0.10
 7  labels:
 8    app: test
 9    version: v1
10---
11apiVersion: networking.istio.io/v1beta1
12kind: WorkloadEntry
13metadata:
14  name: test2-we
15spec:
16  address: 192.168.0.11
17  labels:
18    app: test
19    version: v2
20---
21apiVersion: networking.istio.io/v1beta1
22kind: WorkloadEntry
23metadata:
24  name: test3-we
25spec:
26  address: 192.168.0.12
27  labels:
28    app: test
29    version: v2

我们在 ServiceEntry 对象中只需要将 workloadSelector 的标签设置为 app: test 即可，这样就会将这三个实例都关联到这个 ServiceEntry 对象中，然后我们就可以通过 version 标签来区分不同的实例了。

 1apiVersion: networking.istio.io/v1beta1
 2kind: ServiceEntry
 3metadata:
 4  name: test-se
 5spec:
 6  hosts:
 7    - test.internal.com
 8  ports:
 9    - number: 80
10      name: http
11      protocol: HTTP
12  location: MESH_INTERNAL
13  resolution: STATIC
14  workloadSelector:
15    labels:
16      app: test

不同端口

在大多数情况下，服务和实例的端口我们都可以在 ServiceEntry 对象中进行统一的定义，在WorkloadEntry 对象中我们只需要指定 address 和 labels 字段即可，但是如果我们的服务和实例的端口不一致，那么我们就需要在 WorkloadEntry 对象中指定 ports 字段，比如有两个虚拟机上面的实例分别在 8091 和 8092 端口上接收流量，这种方式在传统的微服务场景中比较常见，一个服务的多个实例被部署在同一个虚拟机上面，但是每个实例都使用不同的端口，这种方式可以避免端口冲突。

创建一个如下所示的 WorkloadEntry 对象：

 1apiVersion: networking.istio.io/v1beta1
 2kind: WorkloadEntry
 3metadata:
 4  name: test1-we
 5spec:
 6  address: 192.168.0.10
 7  labels:
 8    app: test
 9    version: v1
10  ports:
11    http: 8091
12---
13apiVersion: networking.istio.io/v1beta1
14kind: WorkloadEntry
15metadata:
16  name: test2-we
17spec:
18  address: 192.168.0.12
19  labels:
20    app: test
21    version: v2
22  ports:
23    http: 8092

权重

此外 WorkloadEntry 对象中我们还可以通过 weight 字段来指定与端点关联的负载均衡权重，具有较高权重的端点将获得相应比例的流量。

比如我们可以创建一个如下所示的 WorkloadEntry 对象：

 1apiVersion: networking.istio.io/v1beta1
 2kind: WorkloadEntry
 3metadata:
 4  name: test1-we
 5spec:
 6  address: 192.168.0.10
 7  labels:
 8    app: test
 9    version: v1
10  ports:
11    http: 8091
12  weight: 20
13---
14apiVersion: networking.istio.io/v1beta1
15kind: WorkloadEntry
16metadata:
17  name: test2-we
18spec:
19  address: 192.168.0.12
20  labels:
21    app: test
22    version: v2
23  ports:
24    http: 8092
25  weight: 80

在上面的 WorkloadEntry 对象中我们指定了 weight 字段，这个字段用于指定权重，这样就可以实现流量的分流了。

位置

另外 WorkloadEntry 对象中还有一个 locality 字段，这个字段用于指定与端点相关联的位置，位置对应于故障域（例如国家/地区/区域）。可以通过使用 / 来分隔每个封装的故障域来表示任意故障域层次结构。例如，位于美国（US）的端点的位置，在 US-East-1 地区，在可用性区域 az-1 中，在数据中心机架 r11 中就可以表示为 us/us-east-1/az-1/r11。Istio 将配置 sidecar 将路由到与 sidecar 相同位置的端点。如果本地不存在可用的端点，则将选择上级位置（但在相同的网络 ID 中）。例如，如果同一网络（网络 ID n1）中有两个端点，一个位于位置 us/us-east-1/az-1/r11 的端点 e1，另一个位于 us/us-east-1/az-2/r12 的端点 e2，那么来自 us/us-east-1/az-1/r11 位置的 sidecar 将优先选择来自相同位置的 e1，而不是来自不同位置的 e2。

 1apiVersion: networking.istio.io/v1beta1
 2kind: WorkloadEntry
 3metadata:
 4  name: test1-we
 5spec:
 6  address: 192.168.0.10
 7  labels:
 8    app: test
 9    version: v1
10  ports:
11    http: 8091
12  locality: us/us-east-1/az-1/r11
13---
14apiVersion: networking.istio.io/v1beta1
15kind: WorkloadEntry
16metadata:
17  name: test2-we
18spec:
19  address: 192.168.0.20
20  labels:
21    app: test
22    version: v2
23  ports:
24    http: 8092
25  locality: us/us-east-1/az-2/r12

上面的 WorkloadEntry 对象中我们指定了 locality 字段，这个字段用于指定与端点相关联的位置，当然还是需要一个 ServiceEntry 对象来关联这两个 WorkloadEntry 对象，这里就不再赘述了。

除了通过配置 sidecar 之外我们也可以在 DestinationRule 对象中指定 localityLbSetting 字段来指定位置的负载策略，比如我们可以创建一个如下所示的 DestinationRule 对象：

 1apiVersion: networking.istio.io/v1alpha3
 2kind: DestinationRule
 3metadata:
 4  name: test-dr
 5spec:
 6  host: test.internal.com
 7  trafficPolicy:
 8    loadBalancer:
 9      consistentHash:
10        useSourceIp: true
11      localityLbSetting:
12        enabled: true
13        failover:
14          - from: us/us-east-1/az-1/r11
15            to: us/us-east-1/az-2/r12
16          - from: us/us-east-1/az-2/r12
17            to: us/us-east-1/az-1/r11
18    outlierDetection:
19      consecutive5xxErrors: 1
20      interval: 1s
21      baseEjectionTime: 1m

在上面的 DestinationRule 对象中我们指定了 localityLbSetting 字段，这个字段用于指定位置的负载均衡设置，其中我们通过 failover 字段指定了故障转移策略，当 us/us-east-1/az-1/r11 位置的端点不可用时，就会将流量转移到 us/us-east-1/az-2/r12 位置的端点上，当 us/us-east-1/az-2/r12 位置的端点不可用时，就会将流量转移到 us/us-east-1/az-1/r11 位置的端点上。

2、WorkloadGroup

除了支持通过 WorkloadEntry 创建服务实例之外，Istio 还引入了一个 WorkloadGroup 资源对象，该资源对象描述了一组工作负载实例，它提供了一个规范，工作负载实例可以使用该规范来引导其代理，包括元数据和身份信息。它仅用于非 Kubernetes 工作负载（如虚拟机）。

WorkloadGroup 对象的定义和 Deployment 非常类似，比如我们可以定义一个如下所示的 WorkloadGroup 对象：

 1apiVersion: networking.istio.io/v1beta1
 2kind: WorkloadGroup
 3metadata:
 4  name: test-wg
 5spec:
 6  metadata:
 7    labels:
 8      app: test
 9  template:
10    ports:
11      http: 8091
12    serviceAccount: default
13  probe:
14    httpGet:
15      path: /health
16      port: 8091

WokloadGroup 对象中描述了一个负载的模板，这个模板可以用来动态生成 WorkloadEntry 的服务实例，类似在 Kubernetes 中的 Deployment 对象中的模板生成 Pod 实例。

上面的示例中可以看到 WorkloadGroup 对象中并不涉及到服务访问的 Host 等信息，同样的服务相关的定义还是需要通过 ServiceEntry 来定义。

WorkloadGroup、WorkloadEntry 和 ServiceEntry 三者之间的关系就和 Kubernetes 中的 Deployment、Pod 和 Service 三者之间的关系类似，如下表所示：


对比项	Kubernetes	虚拟机
基础调度实体	Pod	WorkloadEntry
编排组合	Deployment	WorkloadGroup
服务注册与发现	Service	ServiceEntry

整体上 WorkloadGroup 对象的核心包括三个字段： metadata、template 与 probe。

metadata：这个字段用来定义在 WorkloadEntry 上生成的元数据信息，包括标签、注解等信息。
template：定义 WorkloadEntry 的模板，需要注意该模板里面只配置负载通用的信息，无须配置实例地址和实例标签等服务实例的自身信息。
probe：和 Kubernetes 中的健康检查类似的配置和机制，只有探针通过的实例才被注册到服务段，否则不会被注册。WorkloadGroup 支持配置 HTTP、TCP 和 EXEC 三种类型的探针。

WorkloadGroup 主要用于虚拟机服务的自动注册，比如在每个虚拟机节点上部署的服务网格数据面都连接到控制面 Istiod，控制面会根据配置的 WorkloadGroup 信息自动创建 WorkloadEntry 实例，在后面虚拟机章节中再和大家演示，这里就不再赘述了。