2023超详细！15分钟把虚拟机拉进Istio服务网格，老应用秒变云原生

2023超详细！15分钟把虚拟机拉进Istio服务网格，老应用秒变云原生

一、为啥要把虚拟机拉进服务网格？

想象一下，你家小区有两个物业公司：一个管新建的高楼（K8s容器），一个管老楼（虚拟机）。两边老死不相往来，快递（流量）送不到，保安（安全策略）各管各的。Istio就像新成立的业主委员会，把两边统一管理起来——这就是把虚拟机纳入服务网格的意义。

现在企业里，70%的应用还跑在虚拟机上，但又想享受容器化带来的流量管理、安全加密、可观测性这些好处。Istio从1.6版本开始支持这个需求，到1.14已经相当成熟了。就像给老楼装了电梯，不用搬家也能享受新设施。

二、两种组网方案：选哪种合适？

2.1 单网络架构（推荐新手）

就像同一栋楼不同单元：K8s集群和虚拟机在同一个局域网，能直接串门。控制平面（Istiod）通过东西向网关给虚拟机发配置和证书，简单直接。

适合场景：

- 虚拟机和K8s集群在同一个VPC

- 网络策略宽松，允许直接通信

- 中小规模部署（10台以内虚拟机）

2.2 多网络架构（进阶玩家）

像两个小区用地下通道连接：K8s在A网段，虚拟机在B网段，通过专用网关（类似小区间的地下通道）通信。所有流量都要经过网关转发，更安全但配置复杂。

适合场景：

- 跨数据中心部署

- 严格的网络隔离要求

- 大规模虚拟机集群（50台以上）

三、核心概念：3个"身份证"要记牢

3.1 WorkloadGroup：给虚拟机办"户口本"

相当于给虚拟机集群办个户口本，记录着这组机器的共同特征：用什么服务账户、什么标签、开哪些端口。就像物业公司登记"3栋全是商户，统一晚上10点关门"。

示例代码（保存为wg.yaml）：

```yaml

apiVersion: networking.istio.io/v1alpha3

kind: WorkloadGroup

metadata:

name: python-http

namespace: vm-namespace

spec:

metadata:

labels:

app: hello-vm 给这组虚拟机贴个标签

template:

serviceAccount: vm-sa 用这个身份访问集群

ports:

http: 80 服务跑在80端口

```

3.2 WorkloadEntry：给每台虚拟机办"身份证"

每台虚拟机的具体信息：IP地址、实例ID、健康状态。就像户口本里的单页，记录"3栋101室，张三，身体健康"。

示例代码（保存为we.yaml）：

```yaml

apiVersion: networking.istio.io/v1beta1

kind: WorkloadEntry

metadata:

name: vm1

namespace: vm-namespace

spec:

address: 192.168.110.140 虚拟机实际IP

labels:

app: hello-vm 和WorkloadGroup对应

instance-id: vm-001 虚拟机唯一标识

serviceAccount: vm-sa 和WorkloadGroup对应

```

3.3 ServiceEntry：给虚拟机服务装"门牌号"

告诉网格："有个叫vm-service.example.com的服务，住在这些WorkloadEntry地址，大家可以通过80端口找它"。就像给小区新增一个门牌号，快递员（流量）就知道往哪送了。

示例代码（保存为se.yaml）：

```yaml

apiVersion: networking.istio.io/v1beta1

kind: ServiceEntry

metadata:

name: vm-service

namespace: vm-namespace

spec:

hosts:

- vm-service.example.com 服务域名

location: MESH_INTERNAL

ports:

- number: 80

name: http

protocol: HTTP

resolution: STATIC

workloadSelector:

labels:

app: hello-vm 匹配带这个标签的WorkloadEntry

```

四、手把手操作：15分钟搞定单网络架构

准备工作清单

- 已安装Istio 1.14的K8s集群（v1.21.9最佳）

- 一台CentOS 7.4虚拟机（2核4G，和K8s在同一网段）

- 所有机器关闭SELinux和防火墙

- 准备好梯子（部分资源需境外访问）

4.1 给K8s集群装"网关"（东西向网关）

先进入Istio安装目录，执行脚本创建东西向网关：

```bash

cd istio-1.14.0

samples/multicluster/gen-eastwest-gateway.sh --single-cluster | istioctl install -y -f -

```

检查网关是否就绪：

```bash

kubectl get pods -n istio-system | grep eastwest

输出类似：istio-eastwestgateway-xxxx 1/1 Running

```

4.2 给虚拟机创建"身份文件"

1. 创建专用命名空间和服务账户：

```bash

export VM_NAMESPACE="vm-namespace"

export SERVICE_ACCOUNT="vm-sa"

kubectl create namespace $VM_NAMESPACE

kubectl create serviceaccount $SERVICE_ACCOUNT -n $VM_NAMESPACE

```

2. 生成连接集群的密钥文件：

```bash

export WORK_DIR="${HOME}/vmfiles"

mkdir -p $WORK_DIR

istioctl x workload entry configure -f wg.yaml -o $WORK_DIR

```

现在`vmfiles`目录里会生成：

- `cluster.env`：集群信息

- `root-cert.pem`：根证书

- `istio-token`：身份令牌

4.3 给虚拟机装"代理"（Sidecar）

1. 把文件传到虚拟机（替换为你的虚拟机IP）：

```bash

scp -r $WORK_DIR root@192.168.110.140:~/

```

2. SSH登录虚拟机，安装依赖：

```bash

yum install -y socat conntrack ipset

```

3. 下载Istio代理安装包（选对应架构）：

```bash

curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.14.0 TARGET_ARCH=x86_64 sh -

cd istio-1.14.0

```

4. 安装Sidecar：

```bash

sudo cp ~/vmfiles/cluster.env /var/lib/istio/envoy/

sudo cp ~/vmfiles/root-cert.pem /var/run/secrets/istio/root-cert.pem

sudo cp ~/vmfiles/istio-token /var/run/secrets/tokens/istio-token

安装代理

sudo ./bin/istioctl workload install -u "istio-proxy" -g "istio-proxy" \

--node-agent-mode ambient --proxy-mode sidecar

```

5. 启动代理并设置开机启动：

```bash

sudo systemctl start istio

sudo systemctl enable istio

```

检查状态：`systemctl status istio`，看到`active (running)`就成功了。

4.4 在虚拟机上跑个服务试试水

启动一个简单的Python服务器：

```bash

nohup python -m SimpleHTTPServer 80 &

```

现在创建前面说的WorkloadEntry和ServiceEntry：

```bash

kubectl apply -f we.yaml -f se.yaml

```

4.5 测试联通性

1. 在K8s集群里起个测试Pod：

```bash

kubectl run test-pod --image=busybox -n default --rm -it -- sh

```

2. 在Pod里访问虚拟机服务：

```bash

wget -qO- vm-service.example.com

应该能看到虚拟机上的文件列表

```

五、新手避坑清单（血的教训）

1. 网络不通先看防火墙：K8s节点和虚拟机之间要开放443、15012、15017端口

2. 证书权限要正确：虚拟机上的`istio-token`文件权限必须是600

3. 时间同步是关键：所有机器时间差不能超过5分钟，否则证书验证失败

4. 标签要统一：WorkloadGroup、WorkloadEntry、ServiceEntry的labels必须匹配

5. 网关IP别写错：生成`cluster.env`时，ISTIOD_ADDR要填东西向网关的ClusterIP

六、常见问题解决

Q1：虚拟机连不上istiod怎么办？

A：先执行`telnet <网关IP> 15012`，如果不通检查：

- 网关服务是否正常：`kubectl get svc istio-eastwestgateway -n istio-system`

- 虚拟机路由是否正确：`route -n`看是否能到达K8s网段

Q2：K8s里ping不通虚拟机IP？

A：Istio默认开启mTLS，不能直接ping。用`istioctl pc endpoints -n default`看是否有虚拟机IP

Q3：ServiceEntry创建后访问报404？

A：检查：

1. WorkloadEntry的address是否正确

2. 虚拟机服务是否监听0.0.0.0（别只绑127.0.0.1）

3. 用`istioctl proxy-status`看虚拟机代理是否已同步配置

Q4：Sidecar启动失败，日志提示"permission denied"？

A：执行`sudo chown -R istio-proxy:istio-proxy /var/lib/istio /var/run/secrets`

Q5：虚拟机上的服务看不到监控数据？

A：修改Istio安装配置，添加：

```yaml

values:

telemetry:

enabled: true

```

七、10个实用小技巧

1. 自动注册WorkloadEntry：安装Istio时加`--set values.pilot.env.PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION=true`，虚拟机启动后自动创建WorkloadEntry

2. 启用智能DNS：安装时添加`--set meshConfig.defaultConfig.proxyMetadata.ISTIO_META_DNS_CAPTURE=true`，虚拟机可以直接用K8s服务名访问

3. 查看流量走向：`istioctl dashboard kiali`，在图形化界面看虚拟机和Pod之间的调用关系

4. 手动注入Sidecar：`istioctl kube-inject -f deployment.yaml | kubectl apply -f -`，给没自动注入的Pod补装代理

5. 修改代理日志级别：`istioctl proxy-config log -n default --level debug`，排错时很有用

6. 测试服务可用性：`istioctl experimental probe vm-service.example.com:80 -n vm-namespace`

7. 导出配置快照：`istioctl x workload entry snapshot -o backup.yaml`，防止配置丢失

8. 限制虚拟机流量：用DestinationRule配置连接池：

```yaml

apiVersion: networking.istio.io/v1alpha3

kind: DestinationRule

metadata:

name: vm-service

namespace: vm-namespace

spec:

host: vm-service.example.com

trafficPolicy:

connectionPool:

tcp:

maxConnections: 100

```

9. 一键重启所有代理：`kubectl rollout restart deployment istio-ingressgateway -n istio-system`

10. 升级Sidecar：`istioctl upgrade -f istio-operator.yaml`，会自动升级所有代理

八、长期使用体验

我在生产环境用这个方案管理20台虚拟机，稳定运行了8个月。最大的感受是：

1. 故障排查变简单了：以前虚拟机服务出问题要登录机器看日志，现在在Kiali上就能看到调用链和错误率

2. 安全合规有保障：所有流量自动加密，不用手动配置SSL证书，通过PCI-DSS认证时省了很多事

3. 资源开销可控：每台虚拟机的Sidecar大约占用50MB内存，CPU使用率通常在5%以下

4. 平滑迁移利器：先把虚拟机纳入网格，再逐步把服务容器化，业务不中断

唯一的缺点是初期配置有点复杂，建议先用3台虚拟机做测试，跑通流程再大规模推广。

话说回来，服务网格的价值就在于让基础设施层替业务解决流量、安全、可观测性这些通用问题。把虚拟机拉进来，正是这个理念的延伸——不管应用跑在哪，都能享受到一致的服务治理能力。这大概就是云原生的终极形态吧。

版权声明：本站所有文章皆为原创，欢迎转载或转发，请保留网站地址和作者信息。