在Fedora上运行Istio，先要确认内核与容器工具链。Istio的控制平面以Kubernetes Deployment形式运行，因此并不依赖Fedora本身的特定版本，但需要本机Kubernetes集群能够正常创建Pod并暴露NodePort或LoadBalancer。对单机入门来说，kind和minikube是最轻量的选择，如果已经有kubeadm搭建的集群也可以直接使用。
Fedora上的Kubernetes与容器运行时准备
Istio不直接管理容器运行时，它依赖Kubernetes调度Pod，再由kubelet调用Docker或containerd启动容器。Fedora默认仓库中的moby-engine可以满足要求，但更推荐安装Docker官方仓库中的docker-ce，因为版本更新更及时，与Kubernetes的兼容性也更容易确认。如果本机已经安装Podman，需要留意Podman的rootless模式与kubelet的通信方式并不完全一致，单机实验建议统一使用Docker作为运行时。
安装Docker后要确认当前用户是否有权访问/var/run/docker.sock。没有权限时kubectl创建Pod会一直卡在Pending状态，看起来像Istio安装失败，实际上问题出在运行时。执行sudo usermod -aG docker $USER并重新登录后，可以运行docker info验证。接下来安装kubectl和minikube，minikube使用Docker驱动时会在本机创建一个单节点Kubernetes集群，省去了手动配置kubelet、证书和网络插件的步骤。
sudo dnf install -y dnf-plugins-core sudo dnf config-manager --add-repo https://download.docker.com/linux/fedora/docker-ce.repo sudo dnf install -y docker-ce docker-ce-cli containerd.io sudo systemctl enable --now docker sudo usermod -aG docker $USER curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 sudo install minikube-linux-amd64 /usr/local/bin/minikube minikube start --driver=docker --cpus=4 --memory=8192 kubectl get nodes
minikube start第一次执行会下载Kubernetes组件镜像，耗时就取决于网络环境。启动完成后，kubectl get nodes应看到节点状态为Ready。如果节点一直NotReady，可以通过minikube logs查看kubelet日志，多数情况下是Docker服务未启动或当前用户没有Docker权限。Fedora的防火墙也可能拦截NodePort流量，后续访问Istio入口网关时如果连接被拒绝，可以用sudo firewall-cmd --add-port=30000-32767/tcp --permanent放行NodePort范围。
安装istioctl并初始化Istio控制平面
istioctl是Istio官方命令行工具，负责安装、升级、调试服务网格。它只是一个二进制文件，可以从GitHub发布页下载，也可以直接读取Istio发布包中的bin/istioctl。下载时建议指定主版本，避免使用latest导致后续YAML字段不兼容。解压后把istioctl移动到/usr/local/bin，这样在任何目录都能直接调用。
安装Istio控制平面之前，需要确认Kubernetes API版本。istioctl会自动检测集群版本，但最好在安装前执行istioctl x precheck检查集群是否满足最低要求。demo profile适合单机实验，它会同时安装istiod、ingress gateway和egress gateway，但不启用生产级的多副本和资源限制。安装过程中istioctl会创建istio-system命名空间，并在其中部署控制平面组件。
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.20.2 sh - cd istio-1.20.2 sudo cp bin/istioctl /usr/local/bin/istioctl istioctl version istioctl x precheck istioctl install --set profile=demo -y kubectl get pods -n istio-system
istioctl install会生成一堆CRD，包括VirtualService、DestinationRule、Gateway、PeerAuthentication等。这些CRD属于Kubernetes API扩展，删除Istio时不能只删除Deployment和Service，必须显式执行istioctl uninstall --purge，否则残留的CRD会让后续安装产生字段冲突。安装完成后，istio-system命名空间中会出现istiod和istio-ingressgateway两个主要Pod，状态应全部为Running。
要让普通业务命名空间中的Pod自动注入Envoy sidecar，需要给命名空间打标签。没有这个标签时，业务Pod虽然能正常启动，但不会进入服务网格，Istio的流量规则也不会生效。执行kubectl label namespace default istio-injection=enabled后，该命名空间下新建的Pod会多出一个istio-proxy容器，它就是每个服务身边的Envoy代理。
部署Bookinfo并验证Sidecar注入
Bookinfo是Istio官方提供的示例应用，由productpage、details、reviews、ratings四个微服务组成。其中reviews服务有三个版本，分别返回不同的图书评价内容，正好用来演示流量分发。部署前先确认default命名空间已经开启了自动注入，否则即便应用启动成功，Kiali中也看不到服务间的流量连线。
kubectl label namespace default istio-injection=enabled kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml kubectl get pods kubectl get services
观察Pod状态时，如果看到READY列为2/2，说明业务容器和sidecar容器都已就绪；如果是1/2，可以执行kubectl describe pod查看sidecar容器的事件。常见原因是Envoy镜像拉取失败，此时需要检查Docker的镜像加速配置或网络代理。Fedora本机实验时，镜像拉取速度会直接影响Istio初体验，可以提前配置好镜像加速地址。
验证自动注入是否生效，还可以用kubectl get pod -o jsonpath='{.spec.containers[*].name}'查看容器列表。输出中会包含istio-proxy，这是Envoy代理的默认容器名。有了Envoy之后，服务之间的HTTP请求不再直接到达业务端口，而是先经过15001端口的sidecar拦截，再由Envoy根据Istio配置转发。这个过程对应用代码完全透明，不需要修改任何Java、Python或Go代码。
使用VirtualService和DestinationRule管理流量
VirtualService定义请求如何路由，DestinationRule定义路由目的地有哪些版本。两者需要配合使用：DestinationRule先声明reviews服务有三个子版本v1、v2、v3，VirtualService再决定把多少流量送到哪个子版本。没有DestinationRule时，VirtualService中的subset无法匹配到具体目标，请求会走Kubernetes默认的负载均衡。
先配置DestinationRule，给reviews的Deployment设置版本标签。Bookinfo示例已经通过app=reviews和version=v1/v2/v3标签区分版本，因此DestinationRule可以直接使用这些标签作为subset。接着创建VirtualService，让所有访问reviews的请求默认打到v1，但如果HTTP Header中end-user的值为jason，则转发到v2版本。这个规则非常适合做灰度发布或A/B测试。
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: reviews-destination
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
- name: v3
labels:
version: v3
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews-route
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v1
weight: 80
- destination:
host: reviews
subset: v3
weight: 20
应用这套规则后，普通用户的请求会有80%进入v1、20%进入v3，而带有end-user: jason请求头的用户会全部进入v2。这样可以在不重新部署应用的前提下完成流量切分。要调整比例，只需修改VirtualService中的weight字段并重新apply，Envoy会在几秒内动态更新路由配置，不需要重启任何Pod。
流量规则的调试不能只看Pod状态，因为VirtualService配置错误时Pod仍然正常运行，但请求会出现404、503或直接走默认负载均衡。使用istioctl analyze可以检查当前命名空间中的配置是否有语法错误或引用不存在的subset。如果规则配置正确但仍不生效，多半是请求没有经过sidecar，常见原因包括命名空间未开启自动注入、应用部署在注入标签添加之前、或者使用了hostNetwork: true绕过Envoy。
通过Kiali观测网格状态与故障排查
Kiali是Istio的可视化面板，可以展示服务拓扑、请求速率、错误率和响应延迟。它不改变任何流量规则，只是一个读取网格配置和Metrics的Web应用。demo profile中Kiali默认不对外暴露，需要通过istioctl dashboard kiali启动本地代理访问。首次打开时需要登录，默认账号密码都是admin，可以在Kiali CR中修改。
kubectl apply -f samples/addons/kiali.yaml kubectl apply -f samples/addons/prometheus.yaml kubectl apply -f samples/addons/jaeger.yaml istioctl dashboard kiali
在Kiali的Graph页面选择default命名空间，可以看到productpage、details、reviews、ratings四个服务之间的连线。连线上的箭头方向表示调用方向，颜色代表健康状态。如果某条连线出现红色，说明错误率超过阈值，可以点击连线查看具体是5xx还是连接超时。通过Header路由实验时，可以在浏览器中反复刷新productpage页面，并在Kiali中观察reviews服务的流量分布是否接近80:20。
Jaeger用于链路追踪，Prometheus用于指标采集。Istio的Envoy代理会自动上报访问日志和指标，但只有Prometheus存在时Kiali的Metrics才会显示，只有Jaeger存在时才能查看单次请求经过哪些服务。实验结束后，如果不再需要这些观测组件，可以删除addons资源，但要注意保留Prometheus CRD并不会影响Istio核心功能。
清理整个Istio环境时，先删除业务命名空间中的Bookinfo资源，再执行istioctl uninstall --purge移除控制平面和CRD。最后停止minikube或删除集群。如果担心minikube的Docker容器占用过多磁盘，可以运行minikube delete --all彻底清理。Fedora本机实验不需要修改系统级配置，整个过程对后续重新搭建也不会有影响。