This message was deleted.
# kubernetesa
adamant-kite-43734
06/20/2023, 8:48 PMThis message was deleted.
b
bulky-computer-31499
06/20/2023, 8:56 PMit sounds like you ended up creating a HostPort binding to the pod instead of a ClusterIP service. A HostPort is defined as part of the pod template in a Deployment, while a ClusterIP or NodePort service are separate declarations
r
rough-exabyte-8533
06/21/2023, 11:10 AMThanks for clarifying that. Can I ask, When I create a NodePort service I can specify a listening port. What is that and how is different than the public host port?
b
bulky-computer-31499
06/21/2023, 1:49 PMNodePorts are in a high port range, 30000-32767 typically. It's used to route incoming requests on that port to any of the pods in a deployment. In contrast, a HostPort is a direct binding from the pod to a port on the host, and a request will go directly to that pod.
bulky-computer-31499
06/21/2023, 1:50 PMWhen creating a NodePort service, the port is configurable, but only within the range the cluster is configured for (in that 30x realm)
bulky-computer-31499
06/21/2023, 1:52 PMa LoadBalancer type service is normally used when you want to expose a service on a particular port that is not tied to a node. In the cloud, this would be a cloud load balancer of some type (alb,nlb, etc). On bare metal, you need to add something to provide this service. The easiest I've used is metal-lb. You provide it a pool/range of private or public IPs separate from the nodes themselves that it can issue and it'll handle creating an endpoint on that IP with an open port (or multiple) bound to your deployment.
bulky-computer-31499
06/21/2023, 1:54 PMone way to expose a service on k8s without metal-lb is using some kind of external load balancer in front of the cluster. You'd publish your service on a nodeport and then add that nodeport and the IPs of your nodes to a separate load balancer/proxy in front of the cluster to route requests
r
rough-exabyte-8533
06/21/2023, 3:00 PMok, thanks again. that helps
3 Views