bureaucraten, interfacemoderatoren, Beheerders (Semantic MediaWiki), Curatoren (Semantic MediaWiki), Redacteuren (Semantic MediaWiki), toezichthouders, beheerders
205
bewerkingen
Projects:Kubernetes: verschil tussen versies
Naar navigatie springen
Naar zoeken springen
→Accessing a deployment using a Service
| Regel 583: | Regel 583: | ||
* <code>NodePort</code> is a service type indicating that the application should be externally accessible using a "service port" on all Nodes. The service port will be allocated by Kubernetes (you can choose it, but that's not recommended) and distributed to all nodes, so that a connection to any node on the service port will automatically end up on one of its running Pods. A NodePort service also automatically gets a ClusterIP, so you can use that, too. | * <code>NodePort</code> is a service type indicating that the application should be externally accessible using a "service port" on all Nodes. The service port will be allocated by Kubernetes (you can choose it, but that's not recommended) and distributed to all nodes, so that a connection to any node on the service port will automatically end up on one of its running Pods. A NodePort service also automatically gets a ClusterIP, so you can use that, too. | ||
* <code>LoadBalancer</code> is a service type indicating that the application should be externally accessible using a provided load balancer. By default, this works like the <code>NodePort</code> but on specific cloud providers you'll also get an allocated external IP address, on which a wanted port is listening and end up on one of the running Pods. I'm running this on my own cluster, not one hosted by a cloud provider, so I won't create a <code>LoadBalancer</code> service. If you'd like to, [https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer this page] explains how they work. | * <code>LoadBalancer</code> is a service type indicating that the application should be externally accessible using a provided load balancer. By default, this works like the <code>NodePort</code> but on specific cloud providers you'll also get an allocated external IP address, on which a wanted port is listening and end up on one of the running Pods. I'm running this on my own cluster, not one hosted by a cloud provider, so I won't create a <code>LoadBalancer</code> service. If you'd like to, [https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer this page] explains how they work. | ||
** There is a controller that allows you to use <code>LoadBalancer</code> services on your own bare-metal cluster that doesn't run on a cloud provider. It's called [https://metallb.universe.tf/ MetalLB] and it works by having a pool of external routable IP addresses to choose from; when allocating from that pool, it starts announcing that IP address via either ARP or BGP onto an arbitrary Node, so that traffic to that IP ends up there. If the Node goes down, MetalLB elects a new leader node and re-announces the IP there, so that the service is moved. | |||
* <code>ExternalName</code> doesn't actually set up any forwarding, but allows you to register an internal name that forwards to a given name in DNS elsewhere. This allows migration to/from Kubernetes. | * <code>ExternalName</code> doesn't actually set up any forwarding, but allows you to register an internal name that forwards to a given name in DNS elsewhere. This allows migration to/from Kubernetes. | ||
* Not a service type, but if your service uses HTTP, you can use Ingress instead of Service to make your service externally accessible. More on that later. | * Not a service type, but if your service uses HTTP, you can use Ingress instead of Service to make your service externally accessible. More on that later. | ||