-
|
Hello I have a general questionning here regarding the managment of k8s clusters in Cloudstack. For security purpose and as designed too by Cloudstack recommendations I keep the Mgmt Network isolated. 4 questions here:
Sorry for all these questions I am kind of lost on this topic based on the existing documentation we have on the 4.20.2.0. My current setup:
...
"domainid": "e5d0db71-bd78-11f0-97ba-d4ae52cfd8f3",
"domainpath": "/",
"endpoint": "",
"hasannotations": false,
"id": "6d06e382-172e-4a2f-ac33-dde8d04b0e3c",
"ipaddress": "10.40.0.13",
...Thank you very much 🙏 |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 2 replies
-
|
@n4l5u0r you can use the management server IP on the endpoint.url , the one on which the Virtual router public IP can reach.
VR public IP to management server API end point is required.
Its a system-wide configuration. |
Beta Was this translation helpful? Give feedback.
-
Ok thank you @rajujith do you mean I have to add mgmt servers to public network for VR requests on public network being able to reach mgmt servers api endpoint which will be http://10.40.0.X:8080/client/api ? The flow direction if I have to secure at firewall level is allowing only one-way direction from VR to port 8080 mgmt server? |
Beta Was this translation helpful? Give feedback.
-
|
The management Server IP and port 8080 need to be reachable from the VR , depending on your network you can either place the management servers in the same network as the public network or do a port forwarding or route etc. Its one way direction from the VR to the 8080 on the management server. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @rajujith created a tunnel between the KVM hosting the VR and the mgmt server and having the VR reaching the Mgmt server IP port 8080: root@r-10-VM:~# curl -I http://10.40.0.7:8080/client/
HTTP/1.1 200 OK
Last-Modified: Thu, 16 Oct 2025 10:51:38 GMT
Content-Type: text/html
Accept-Ranges: bytes
Content-Length: 22989the cluster looks sain : cloud@test-control-19a6d0b97d3:~$ sudo -i
root@test-control-19a6d0b97d3:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
test-control-19a6d0b97d3 Ready control-plane 26m v1.33.1
test-node-19a6d0bc59b Ready <none> 25m v1.33.1
root@test-control-19a6d0b97d3:~# kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system calico-kube-controllers-7bfdc5b57c-czkb2 1/1 Running 0 26m
kube-system calico-node-5ghgz 1/1 Running 0 25m
kube-system calico-node-xfkwd 1/1 Running 0 26m
kube-system coredns-674b8bbfcf-mfp5c 1/1 Running 0 26m
kube-system coredns-674b8bbfcf-z2n5d 1/1 Running 0 26m
kube-system etcd-test-control-19a6d0b97d3 1/1 Running 0 26m
kube-system kube-apiserver-test-control-19a6d0b97d3 1/1 Running 0 26m
kube-system kube-controller-manager-test-control-19a6d0b97d3 1/1 Running 0 26m
kube-system kube-proxy-t46dv 1/1 Running 0 25m
kube-system kube-proxy-xj4mc 1/1 Running 0 26m
kube-system kube-scheduler-test-control-19a6d0b97d3 1/1 Running 0 26m
kubernetes-dashboard dashboard-metrics-scraper-5bd45c9dd6-t7tvb 1/1 Running 0 26m
kubernetes-dashboard kubernetes-dashboard-687457b9bd-sck8x 1/1 Running 0 26mand [root@kvm-host-1-dev ~]# curl -k https://10.40.0.13:6443/version
{
"major": "1",
"minor": "33",
"emulationMajor": "1",
"emulationMinor": "33",
"minCompatibilityMajor": "1",
"minCompatibilityMinor": "32",
"gitVersion": "v1.33.1",
"gitCommit": "8adc0f041b8e7ad1d30e29cc59c6ae7a15e19828",
"gitTreeState": "clean",
"buildDate": "2025-05-15T08:19:08Z",
"goVersion": "go1.24.2",
"compiler": "gc",
"platform": "linux/amd64"
}and the But the k8s cluster remains in Where can I look what is happening ? a specific pod ? |
Beta Was this translation helpful? Give feedback.
-
|
If you observe the logs Cloudstack server continuously poll the Kubernetes API server to check if the nodes are in ready state You can also check the values for reduce it if you need shorter timeout values cloud.kubernetes.cluster.start.timeout |
Beta Was this translation helpful? Give feedback.
-
|
Hello @rajujith & @kiranchavala Thank you very much for your feedbacks! What solved was to allow at network level the TCP on port 8080 from VR to Mgmt server on the same network and redeploy afterwards the k8s. I think this make sens to be added somewhere in the official documentation. As if you plan to have a secure deployment with a clean networks segregation this will be 100% a showstopper. 
Thank you all! 🙏 |
Beta Was this translation helpful? Give feedback.
The management Server IP and port 8080 need to be reachable from the VR , depending on your network you can either place the management servers in the same network as the public network or do a port forwarding or route etc. Its one way direction from the VR to the 8080 on the management server.