dodjdnh opened a new issue, #1570: URL: https://github.com/apache/dubbo-admin/issues/1570
### Environment - Deployment target: Kubernetes - Baseline: `apache/dubbo-admin` `develop` at `bb906476e1aa923d957e6420560ca13aba17524f` - Manifests: `release/kubernetes/` ### Problem The Kubernetes deployment manifests have three packaging/configuration issues: 1. **Missing `dubbo-system` Namespace.** The Nacos and Dubbo Admin resources declare `metadata.namespace: dubbo-system`, but the deployment set does not define that Namespace. The `monitoring` and `dubbo-samples-shop` deployment sets define their own Namespaces. A fresh-cluster deployment should not depend on an undocumented manual prerequisite. The Namespace also needs to be processed before its namespaced resources when applying the `dubbo-system` directory. PR [#1387](https://github.com/apache/dubbo-admin/pull/1387) introduced the manifests with this gap; PR [#1410](https://github.com/apache/dubbo-admin/pull/1410) did not add the missing Namespace. 2. **Invalid Nacos Service.** `release/kubernetes/dubbo-system/nacos.yaml` specifies `type: ClusterIP` while retaining `nodePort: 30848` and `nodePort: 31848`. Kubernetes rejects this combination. PR [#1387](https://github.com/apache/dubbo-admin/pull/1387) originally used a valid `NodePort` Service; PR [#1410](https://github.com/apache/dubbo-admin/pull/1410) changed it to `ClusterIP` without removing the two `nodePort` fields. The included Admin and Shop workloads use the internal `nacos.dubbo-system.svc:8848` address. 3. **Incorrect Grafana service DNS.** The Dubbo Admin ConfigMap uses `http://grafana.monitoringg.svc:3000`, but the Grafana Service is named `grafana` in the `monitoring` Namespace. The address should be `http://grafana.monitoring.svc:3000`. The typo was added to the ConfigMap in PR [#1410](https://github.com/apache/dubbo-admin/pull/1410). ### Reproduction and expected behavior - A check of the baseline manifests finds no `Namespace/dubbo-system` definition. When a Namespace manifest is added after `dubbo-admin.yaml` and `nacos.yaml`, `kubectl apply --dry-run=client -f release/kubernetes/dubbo-system -o name` confirms that the dependent resources are processed first. This establishes the ordering requirement; it is not a fresh-cluster apply result. - Kubernetes server-side dry-run rejects the baseline Nacos Service because `nodePort` may not be set on a `ClusterIP` Service. - The ConfigMap address contains `monitoringg`, while the included Grafana Service uses `monitoring`. The deployment set should define `Namespace/dubbo-system` before the dependent resources, keep Nacos as a valid internal `ClusterIP` Service without `nodePort`, and use the actual Grafana service DNS. This issue is limited to the correctness of the existing Kubernetes deployment manifests. Dashboard provisioning, Jaeger datasource setup, OTel Collector, Instance Trace, logs, and cross-signal navigation are out of scope. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
