Services and Managed Solutions
Once a Kubernetes Deployment is created and running, no one can, by default, access the application outside of the Kubernetes cluster. Kubernetes Deployments aren’t exposed to the world. To allow other people or servers to access a Kubernetes deployment, you must create a Kubernetes Service. A service is an abstract way to make an application visible outside of the Kubernetes cluster.
There are five ways to set up a Kubernetes Service:
ClusterIP: Exposes the Kubernetes Deployment as a Service to a cluster-internal IP address. A cluster-internal IP address is an IP address that the Kubernetes cluster provides to the deployment.
NodePort: Allows a Deployment to be accessed by an external port; for example, a web server running in a container that’s running on port 80 can be accessed via port 8080 from outside the cluster via a “public” IP.
LoadBalancer: A Kubernetes Deployment can be accessed via a load balancer. The load balancer will provide a public IP address that you can access the Kubernetes Service from.
ExternalName: To access the Kubernetes Deployment from a DNS CNAME record specified in the Kubernetes manifest spec
A Kubernetes cluster isn’t a set-and-forget solution. It requires care and feeding to manage the dozens of different resources available. Managing Kubernetes can be a full-time job in itself! What’s the answer? It is Managed Kubernetes.
Since Kubernetes is an open-source product, this means anyone can offer their own version. Just like Linux has distributions, Kubernetes has different “distributions” that various vendors offer to you, the consumer. When you purchase a managed version of Kubernetes, you no longer have to worry about infrastructure and instead focus on maintaining and deploying the application(s).
Microsoft, among others, has its own flavor of Kubernetes called Azure Kubernetes Service (AKS). AKS takes away a lot of the management, leaving your only responsibility to be the Azure Virtual Machines and hosting applications on the cluster. AKS provides many benefits over rolling your own Kubernetes including:
Less management of infrastructure. Azure worries about managing the master node for you, which is less overhead.
Upgrading Kubernetes API versions requires several packages and binaries. With AKS, simply go to the AKS portal and choose what version you want to use.
If a Kubernetes worker node goes down for any reason in a Kubernetes environment that you built manually, you will need to create a new VM, re-install kubectl, re-install Kubernetes, and connect the worker to the master node. In AKS, you simply scale up the workers.
Not only does a service like AKS make the management of the Kubernetes cluster itself easier, but you get the built-in Azure features like Azure Monitor to constantly monitor the health and security of the cluster.