workloadselector: deployment-mystack-nginx Here is how the Kubernetes YAML for our Nginx workload specifying the HostPort setting under the ‘ports’ section looks: Traffic hitting at : is routed to the pod container’s private port. When a HostPort is specified, that port is exposed to public access on the host where the pod container is deployed. Rancher performs this action internally when you select the HostPort for mapping.

The HostPort setting has to be specified in the Kubernetes YAML specs under the ‘Containers’ section while creating the workload in Kubernetes. Let’s look at HostPort and NodePort in some detail. Rancher internally adds the necessary Kubernetes HostPort or NodePort specs while creating the deployments for a Kubernetes cluster. These are the options in Kubernetes for exposing a public port for your workload:Īs seen above, the UI for port mapping is pretty similar to the 1.6 experience. Rancher 2.0 also supports adding port mapping to your workloads deployed on the Kubernetes cluster. This public port routed traffic to the private port of the service containers running on that host. Users could choose a specific port on the host or let Rancher assign a random one, and that port would be opened for public access.

Rancher 1.6 enabled users to deploy their containerized apps and expose them publicly via Port Mapping. Using load balancing solutions is a wide topic and we can look at them separately in later articles. In this article, we will explore various options for exposing your Kubernetes workload publicly in Rancher 2.0 using port mapping. Standard ways for providing external access include exposing public ports on the nodes where the application is deployed or placing a load balancer in front of the application containers.Ĭattle users on Rancher 1.6 are familiar with port mapping to expose services. Real world applications deployed using containers usually need to allow outside traffic to be routed to the application containers.

Docker port map