Linux系统安装配置Verrazzano 企业级容器平台部署

Linux系统安装配置Verrazzano 企业级容器平台部署

Verrazzano不是一键安装型平台，需Kubernetes集群就绪（节点Ready、CNI就位、无swap、内核参数合规）、operator真实启动（日志含“Reconciling Verrazzano”）、镜像可拉取、ingress网关类型与环境匹配，且dev profile的自签名证书需适配浏览器校验。

先说一个核心结论：Verrazzano 并非那种“一键安装”的轻量级平台。它的顺利启动，高度依赖于底层 Kubernetes 集群的稳定性、网络插件的兼容性以及存储的完备性。如果跳过了关键的等待环节，比如不执行 kubectl -n verrazzano-install rollout status deployment/verrazzano-platform-operator 来确认状态，那么十有八九会遇到 Pod 卡在 CrashLoopBackOff 或 Pending 状态的窘境。

确认 Kubernetes 集群已就绪且满足 Verrazzano 最低要求

Verrazzano 对集群状态的要求相当“挑剔”，绝非简单地执行 kubectl get nodes 看到输出就算万事大吉。许多安装失败的根源，其实都藏在节点状态或网络插件这些基础环节里。

• 节点状态必须彻底 Ready： 所有节点的状态必须明确为 Ready，而不是 NotReady 或 Unknown。同时，通过 kubectl get nodes -o wide 查看的 INTERNAL-IP 必须确保在集群网络内可路由。在一些特殊的私有化部署环境中，经过 NAT 转换后的节点 IP 可能无法被其他 Pod 访问，这会导致 operator 无法拉取镜像或调度组件，问题往往就出在这里。
• CNI 插件是硬性前提： Verrazzano 默认依赖于 Calico 或 Flannel 这类 CNI 插件。如果使用的是 canal.yaml（Calico 与 Flannel 的混合方案），务必确认 calico-node 和 canal 这两个 DaemonSet 都处于 Running 状态，并且使用 calicoctl get nodes 命令能列出所有节点。
• Swap 必须关闭： 检查集群初始化时是否已禁用 Swap。Verrazzano 的组件 Pod 一旦检测到系统开启 Swap，会直接拒绝启动，错误日志中通常会包含 "running with swap on is not supported" 这样的明确提示。
• 内核参数不容忽视： 内核参数 net.bridge.bridge-nf-call-iptables 必须设置为 1。如果这个参数缺失或为0，会导致 Istio sidecar 注入失败，进而使得 istio-system 命名空间下的 Pod 大量陷入 Init:CrashLoopBackOff 的状态。

安装 platform operator 时必须验证 pod 真实就绪而非仅 “Running”

看到 verrazzano-platform-operator 的 Pod 状态显示为 1/1 Running 时，先别急着庆祝。这并不等同于它已经可用——它可能仍然卡在拉取镜像、连接 API Server 或初始化 CRD 的阶段。

• 查验日志是关键： 执行 kubectl -n verrazzano-install logs -l app=verrazzano-platform-operator --tail=50，重点观察日志末尾几行。如果出现了 "Starting manager" 和 "Reconciling Verrazzano" 这样的信息，才说明 operator 真正启动了。反之，则意味着它仍在初始化或遇到了问题。
• 警惕 CRD 冲突： 如果日志卡在 "Waiting for CRD installation"，很大概率是遇到了 RBAC 权限不足，或者集群中已存在同名的 CRD 导致冲突（尤其是在重装场景下）。这时需要手动清理：先通过 kubectl get crd | grep verrazzano 找到相关 CRD，再用 kubectl delete crd 将其删除。
• 镜像拉取是常见瓶颈： operator 的镜像默认从公网仓库拉取。在离线环境中，必须提前通过 docker pull 和 docker tag 将镜像准备到私有仓库中，并修改 operator.yaml 文件里的 image: 字段指向私有仓库地址。否则，Pod 会一直处于 ImagePullBackOff 状态。

dev profile 安装后无法访问 ingress gateway 的典型原因

在部署完 Verrazzano 自定义资源后，如果发现 istio-ingressgateway 这个 Service 一直没有分配到 EXTERNAL-IP，或者 nip.io 域名解析失败，问题往往不在 Verrazzano 平台本身，而在于环境适配。

• 云环境负载均衡器配置： 在 OCI/OKE 这类云平台上，需要为 Service 显式添加特定的注解，例如 service.beta.kubernetes.io/oci-load-balancer-shape: flexible。如果没有正确配置，LoadBalancer 类型的 Service 就会一直处于 Pending 状态。
• 裸金属或本地环境适配： 在没有云负载均衡器的裸金属或本地环境中，需要用 NodePort 或 HostNetwork 模式来替代 LoadBalancer。最直接的方法是修改 istio-ingressgateway Service 的配置，将 type 改为 NodePort，并确保对应的端口（如 31380、31390）在主机防火墙上已开放。
• DNS 解析的坑： nip.io 依赖 DNS 解析。如果本地的 /etc/resolv.conf 指向了不可靠的 DNS 服务器（比如某些会屏蔽外部域名的企业内网 DNS），就会导致解析失败。一个更可靠的验证方法是直接使用 curl 命令并指定 Host 头：curl -H "Host: app.dev.192.168.1.100.nip.io" http://192.168.1.100:31380。
• 检查所有关联 Pod： 务必确认 verrazzano-system 和 istio-system 这两个核心命名空间下的所有 Pod，其 READY 状态都达到了预期（例如 1/1 或 2/2）。任何一个 Pod 出现 0/1 这样的未就绪状态，都可能导致整个网关链路中断。

最后，还有一个最容易被忽略的细节：Verrazzano 的 dev 配置文件默认会启用自签名证书。然而，部分现代浏览器（如 Chrome 120+ 版本）对 nip.io 这类域名的证书校验变得更为严格。即使使用了 --resolve 参数，也可能遇到 SSL_ERROR_BAD_CERT_DOMAIN 错误。此时，正确的解决思路是使用 curl -k 参数临时跳过证书验证，或者将平台的 CA 证书临时导入到系统或浏览器中，而不是反复尝试重装整个平台，那纯粹是徒劳无功。