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-ingressgatewayService 的配置，将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" https://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 证书临时导入到系统或浏览器中，而不是反复尝试重装整个平台，那纯粹是徒劳无功。
