Merge pull request #1 from mas-synaigy/patch-13

mas-synaigy · web-flow · commit 23f939b28bc6 · 2024-05-08T12:41:45.000+02:00
Update guide.it-it.md
diff --git a/pages/public_cloud/containers_orchestration/managed_kubernetes/using-lb/guide.it-it.md b/pages/public_cloud/containers_orchestration/managed_kubernetes/using-lb/guide.it-it.md
@@ -62,6 +62,10 @@ It's rather cumbersome to use `NodePort` `Services` in production. As you are us
 >
 > In this case the *nodes* URL will be `https://xxxxxx.nodes.c1.gra9.k8s.ovh.net` and a service deployed on NodePort 30123 can be accessed on `https://xxxxxx.nodes.c1.gra9.k8s.ovh.net:30123`.
 
+> [!warning]
+> If your OVHcloud Managed Kubernets is connected to a vRack the `NodePort` is only exposed on your private Subnet. So you have to check your private IPs on your nodes in your Nodepool and you can
+> connect via one of these private IPs.
+
 ### Exposing services as LoadBalancer
 
 Declaring a service of type `LoadBalancer` exposes it externally using a cloud provider’s load balancer. The cloud provider will provision a load balancer for the `Service`, and map it to its automatically assigned `NodePort`. How the traffic from that external load balancer is routed to the `Service` pods depends on the cluster provider.

Original file line number	Diff line number	Diff line change
@@ -62,6 +62,10 @@ It's rather cumbersome to use `NodePort` `Services` in production. As you are us
`62`	`62`	`>`
`63`	`63`	> In this case the nodes URL will be `https://xxxxxx.nodes.c1.gra9.k8s.ovh.net` and a service deployed on NodePort 30123 can be accessed on `https://xxxxxx.nodes.c1.gra9.k8s.ovh.net:30123`.
`64`	`64`
	`65`	`+> [!warning]`
	`66`	+> If your OVHcloud Managed Kubernets is connected to a vRack the `NodePort` is only exposed on your private Subnet. So you have to check your private IPs on your nodes in your Nodepool and you can
	`67`	`+> connect via one of these private IPs.`
	`68`	`+`
`65`	`69`	`### Exposing services as LoadBalancer`
`66`	`70`
`67`	`71`	Declaring a service of type `LoadBalancer` exposes it externally using a cloud provider’s load balancer. The cloud provider will provision a load balancer for the `Service`, and map it to its automatically assigned `NodePort`. How the traffic from that external load balancer is routed to the `Service` pods depends on the cluster provider.