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 来确认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 域名解析失败，问题往往在于环境适配，而非平台本身。

• 云环境负载均衡器配置： 在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证书临时导入系统或浏览器，而非反复尝试重装整个平台。