![]() The ClusterIP enables the applications running within the pods to access the service. By default Kubernetes services are accessible at the ClusterIP which is an internal IP address reachable from inside of the Kubernetes cluster only. The NodePort setting applies to the Kubernetes services. ![]() These containers are configured to use hostPorts 80 and 443 to allow the inbound traffic on these ports from the outside of the Kubernetes cluster. Ingress controller is deployed as a set of containers running on top of Kubernetes. What is the hostPort used for? For example, the nginx based ![]() The host IP can change when the container is restarted, two containers using the same hostPort cannot be scheduled on the same node and the usage of the hostPort is considered a privileged operation on OpenShift. Using the hostPort to expose an application to the outside of the Kubernetes cluster has the same drawbacks as the hostNetwork approach discussed in the previous section. The hostPort feature allows to expose a single container port on the host IP. Here comes a sample pod definition: influxdb-hostport.yml The container port will be exposed to the external network at :, where the hostIP is the IP address of the Kubernetes node where the container is running and the hostPort is the port requested by the user. The hostPort setting applies to the Kubernetes containers. Due to hostNetwork: true the Flannel has full control of the networking on every node in the cluster allowing it to manage the overlay network to which the pods with hostNetwork: false are connected to. For example, the Kubernetes networking plugin Flannel can be deployed as a daemon set on all nodes of the Kubernetes cluster. What is the host networking good for? For cases where a direct access to the host networking is required. For these reasons, the host networking is not a good way to make your applications accessible from outside of the cluster. On top of that, creating a pod with hostNetwork: true on OpenShift is a privileged operation. This can lead to port conflicts when the number of applications running on the cluster grows. Besides that two applications requiring the same port cannot run on the same node. Note that every time the pod is restarted Kubernetes can reschedule the pod onto a different node and so the application will change its IP address. InfluxDB will respond with HTTP 204 No Content when working properly. Remember to replace the host name in the above URL with the host name or IP address of the Kubernetes node where your pod has been scheduled to run.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |