Skip to content

Latest commit

 

History

History
86 lines (69 loc) · 5.66 KB

cs_network_planning.md

File metadata and controls

86 lines (69 loc) · 5.66 KB
copyright lastupdated
years
2014, 2018
2018-03-30

{:new_window: target="_blank"} {:shortdesc: .shortdesc} {:screen: .screen} {:pre: .pre} {:table: .aria-labeledby="caption"} {:codeblock: .codeblock} {:tip: .tip} {:download: .download}

Planning networking with NodePort, LoadBalancer, or Ingress services

{: #planning}

When you create a Kubernetes cluster in {{site.data.keyword.containerlong}}, every cluster must be connected to a public VLAN. The public VLAN determines the public IP address that is assigned to a worker node during cluster creation. {:shortdesc}

The public network interface for the worker nodes in both free and standard clusters is protected by Calico network policies. These policies block most inbound traffic by default. However, inbound traffic that is necessary for Kubernetes to function is allowed, as are connections to NodePort, LoadBalancer, and Ingress services. For more information about these policies, including how to modify them, see Network policies.

Cluster type Manager of the public VLAN for the cluster
Free clusters in {{site.data.keyword.Bluemix_notm}} {{site.data.keyword.IBM_notm}}
Standard clusters in {{site.data.keyword.Bluemix_notm}} You in your IBM Cloud infrastructure (SoftLayer) account
{: caption="VLAN management responsibilities" caption-side="top"}

For information about in-cluster network communication between worker nodes and pods, see In-cluster networking. For information about securely connecting apps that run in a Kubernetes cluster to an on-premises network or to apps that are external to your cluster, see Setting up VPN connectivity.

Allowing public access to apps

{: #public_access}

To make an app publicly available to the internet, you must update your configuration file before you deploy the app into a cluster. {:shortdesc}

Kubernetes data plane in {{site.data.keyword.containershort_notm}}

{{site.data.keyword.containerlong_notm}} Kubernetes architecture

The diagram shows how Kubernetes carries user network traffic in {{site.data.keyword.containershort_notm}}. Depending on whether you created a free or a standard cluster, different ways exist to make your app accessible from the internet.

NodePort service (free and standard clusters)
  • Expose a public port on every worker node and use the public IP address of any worker node to publicly access your service in the cluster.
  • Iptables is a Linux kernel feature that load balances requests across the app's pods, provides high-performance networking routing, and provides network access control.
  • The public IP address of the worker node is not permanent. When a worker node is removed or re-created, a new public IP address is assigned to the worker node.
  • The NodePort service is great for testing public access. It can also be used if you need public access for only a short amount of time.
LoadBalancer service (standard clusters only)
  • Every standard cluster is provisioned with four portable public and four portable private IP addresses that you can use to create an external TCP/UDP load balancer for your app.
  • Iptables is a Linux kernel feature that load balances requests across the app's pods, provides high-performance networking routing, and provides network access control.
  • The portable public IP address that is assigned to the load balancer is permanent and does not change when a worker node is re-created in the cluster.
  • You can customize your load balancer by exposing any port that your app requires.
Ingress (standard clusters only)
  • Expose multiple apps in your cluster by creating one external HTTP or HTTPS, TCP, or UDP load balancer that uses a secured and unique public entrypoint to route incoming requests to your apps.
  • You can use one public route to expose multiple apps in your cluster as services.
  • Ingress consists of two components:
    • The Ingress resource defines the rules for how to route and load balance incoming requests for an app.
    • The application load balancer (ALB) listens for incoming HTTP or HTTPS, TCP, or UDP service requests and forwards requests across the apps' pods based on the rules that you defined in the Ingress resource.
  • Use Ingress if you want to implement your own ALB with custom routing rules and if you need SSL termination for your apps.

To choose the best networking option for your application, you can follow this decision tree. For planning information and configuration instructions, click on the networking service option that you choose.

This image walks you through choosing the best networking option for your application. If this image is not displaying, the information can still be found in the documentation.