虚拟机调试

    对 Istio 部署至虚拟机进行故障排除跟对 Kubernetes 内运行的代理问题进行故障排除是类似的,但还是有一些关键点需要注意。

    虽然在两个平台上都可以获得许多相同的信息,但对这些信息的访问是不同的。

    Istio sidecar 通常作为一个 服务(unit)运行。您可以检查其状态来确保运行正常:

    除此之外您还可以在端点(endpoint)侧以编程的方式检查来 sidecar 的运行情况:

    1. $ curl localhost:15021/healthz/ready -I

    日志

    访问 systemd 日志获取有关于代理的初始化信息:

      代理会将 stderr 日志和 stdout 日志分别重定向到 /var/log/istio/istio.err.log/var/log/istio/istio.log。 你可以以类似于 kubectl 的格式查看这些内容:

      修改配置文件 cluster.env 可以调整日志级别。如果 istio 已经在运行,请务必重新启动服务:

      1. $ systemctl restart istio

      确保 iptables 规则已经生效:

      1. $ sudo iptables-save
      2. ...
      3. -A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
      4. -A ISTIO_OUTPUT -j ISTIO_REDIRECT

      Istioctl

      然而由于 istioctl proxy-config 依赖于 Kubernetes 中的连接代理的功能,因此这对条指令无法在虚拟机环境工作。 不过我们可以传递一个包含 Envoy 配置的文件来替代,举例:

      1. $ curl -s localhost:15000/config_dump | istioctl proxy-config clusters --file -
      2. istiod.istio-system.svc.cluster.local 443 - outbound EDS
      3. istiod.istio-system.svc.cluster.local 15010 - outbound EDS
      4. istiod.istio-system.svc.cluster.local 15012 - outbound EDS
      5. istiod.istio-system.svc.cluster.local 15014 - outbound EDS

      当虚拟机连接到 Istiod 时,会自动创建一个 workloadEntry。 这使得虚拟机成为 service 的一部分,类似于 Kubernetes 中的 endpoint

      检查这些配置是否正确创建:

      1. $ kubectl get workloadentries
      2. NAME AGE ADDRESS
      3. vm-10.128.0.50 14m 10.128.0.50

      证书

      虚拟机处理证书的方式与 Kubernetes Pods 不同,Kubernetes Pods 使用 Kubernetes 提供的 SA 令牌来(service account token)来验证和续订 mTLS 证书。虚拟机则是使用现有的 mTLS 凭据向证书颁发机构进行身份验证并续订证书。

      除此之外, 这些证书需要持久化到磁盘上,以确保停机或重新启动不会丢失。

      1. cert-chain.pem key.pem root-cert.pem