In Kubernetes, a host port configuration allows you to expose a port from your container to the host node's interface. This enables external systems to access a service inside a container through the host node's IP address and the specified host port.
There are a few specific scenarios where using hostPort could be beneficial, such as when you’re trying to test something quickly or want to try it out for development purposes. When you are working with a legacy application that is designed to communicate on a specific port (and refactoring the application to fit the Kubernetes model is not possible) you might be able to use hostPort to meet those requirements. Similarly, if your application has specific networking requirements that can't be easily met using the typical Kubernetes networking model, you might resort to using hostPort. You might also use hostPort if you're deploying system-level or node-level monitoring tools or agents that must be accessed via a specific port on every node, or if you have non-HTTP/HTTPS workloads, and NodePort or LoadBalancer are not suitable for your specific use case.
Using hostPort comes with some downsides, however, such as potentially limiting the scheduling of your pods (because each node can only bind once to a specific hostPort) and possible port conflicts with other services on your nodes. Generally, you should only use hostPort as a last resort, when other methods of exposing your application are not suitable or possible.
Here's an example of how you might define a hostPort in a Kubernetes pod specification:
apiVersion: v1 kind: Pod metadata: name: my-new-pod spec: containers: - name: my-new-container image: my–new-image ports: - containerPort: 8080 hostPort: 8081
In this example, the containerPort is the port where the application inside the container is running, and the hostPort is the port on the host node's network interface that this container port is mapped to. The application in the container can be accessed externally using the host's IP address and port 8081.
However, it's important to understand that using host ports in Kubernetes can have some significant drawbacks, including:
Port Conflicts: These conflicts occur because the host port namespace is shared among all pods, all nodes, and the host itself. If you have multiple pods trying to bind to the same host port, or if a system process on the host is using the same port, this causes conflicts.
Scheduling Constraints: When you specify a hostPort for a pod, the Kubernetes scheduler needs to find a node with that port available, which limits where the pod can be scheduled.
Security Risks: Exposing the hostPort can open up network pathways into your cluster, posing a security risk.
Because of these issues, it’s generally not a good idea to use host ports in Kubernetes. Instead, there are other methods available to expose your services, such as:
NodePort: A NodePort service exposes a pod's port on each node in your cluster using a static port in the range 30000-32767, which offers greater flexibility. The NodePort is automatically available on the node's IP at the specified port number.
LoadBalancer: If your cluster is running on a cloud provider that supports a LoadBalancer service, you can use that. It creates an external load balancer in the current in-cloud network and assigns a fixed, external IP to the service.
Ingress: An Ingress is an API object that manages external access to the services in a cluster, typically via HTTP. Ingress can provide load balancing, SSL termination, and name-based virtual hosting.
The method you choose is dependent on your application's needs and the environment your cluster is running in. So, how can you find out if you have hostPort configured and how can you fix it?
Fairwinds Insights scans containers to see whether host port is configured. If you’re not using Insights, you can use the Insights free tier to find out whether you have host ports configured. This tier is for environments up to 20 nodes, two clusters, and one repo and it helps you get more details and live links that describe how to resolve the action item.
Let’s walk through an example (you can follow along in this video). Basically, what you need to do is go into Insights to find this Action Item, locate exactly where it is in the cluster, and remediate it. It should look something like this:
Screenshot of Insights Host port should not be configured Action Items
This screenshot shows a filtered view of action items on a cluster, showing all of the specific action items for the host port not being configured. Looking at one of them, it shows the Report, Namespace, Kind, Resource Name, and Container for each item, as well as a description and remediation information.
In the video, this action item is in the namespace, Kube2iam, it's a DaemonSet, and the resource name is Kube2iam. What you need to do now is go into the cluster and find that configuration. Once you find that configuration, you can pull the YAML file, and look for where hostPort is configured. In the example, you can see the host port is configured for port 8181. To remediate this action item, you should remove this so it can be allowed to be scheduled in a cluster, and that will resolve that action item.
Remember that while hostPort can be useful in some specific cases, it actually opens you up to some security risk. It’s not considered severe (it’s ranked as Medium in Insights), but there are other ways to enable external systems to access a service inside a container that offer a better, more secure option.
Watch the video to walk through how to check your host port configurations with Fairwinds Insights one step at a time.