In this lesson, I cover just a few of the issues you might

consider when planning your Kubernetes' cluster deployment.

For more articles and advice on cluster planning,

see the IBM Cloud blog.

One of the first questions that you might ask is: where will you run Kubernetes?

You have several options,

which include running Kubernetes on a personal computer,

a virtual machine, bare metal servers,

in your own data center,

or with a cloud service provider.

If you are looking to use Kubernetes as a service,

IBM Cloud Container Service provides a managed Kubernetes environment.

To host Kubernetes in your own data center,

you can use IBM Cloud Private,

or you can combine different environments for a hybrid approach.

The answer will depend on your organization's overall strategy and resources.

To take full advantage of Microservices' architecture,

you might consider how to handle service registry and discovery.

The good news is that Kubernetes natively supports service registry,

discovery, and load balancing.

You can leverage the Kubernetes Service type to expose your Microservices,

and then they can automatically register with the Kubernetes system

by using a virtual IP address or DNS approach.

Discovery is through DNS look-up.

For service-based clusters, Kubernetes provides

a built-in load balancer to distribute the workload among Pods.

Kubernetes exposes the service virtual IP address within the cluster,

so that other pods and services can invoke

the target service via an environment variable.

However, since IP addresses in a cluster can change,

it is generally not a good idea to depend on them.

Instead, you can invoke a service by using a REST endpoint,

which abstracts the application from the underlying infrastructure.

This approach requires the Kubernetes DNS plug-in,

but if you are using IBM Cloud Container Service,

this feature is already installed in your cluster.

Most organizations do not want to expose sensitive data directly to the internet,

so another decision you must make is how to expose the services you want externally.

Typically, you can build a back-end for front-end (BFF)

or API gateway to control access to back-end resources.

Then, the requests go through the Kubernetes internal network,

which can be handled by load balancer, ingress, or NodePort.

You can use NodePort in a development environment,

and you used it in this course,

but you don't want to use it for production environment.

That leaves the load balancer and ingress options.

Load balancer provides an externally accessible IP address,

that sends traffic to the appropriate port on your cluster nodes.

It is easy to enable and allows your client application to

use a REST API through a service-defined http path.

The disadvantage of using load balancer is that it consumes more IP addresses,

which are a billable resource and it depends on the Cloud vendor implementation.

Also, it has no central entry point to handle common tasks,

such as TLS termination.

Instead of using load balancer to create an IP address for each service,

you can use ingress to provide

a unique public route that forwards requests to services in your cluster,

based on their individual paths.

This approach provides a central entry point for your application.

You can add DNS route and global load balancing across multiple Kubernetes regions.

The disadvantage is that the ingress controller is not yet

flexible enough to handle complex application and service routing paths,

terminating TLS, or filtering incoming requests.

Cluster planning considerations

IBM Cloud: Deploying Microservices with Kubernetes

Rencontrer les enseignants