Managed Kubernetes

Most companies do not build their own clusters from scratch. They use a managed Kubernetes service from a cloud provider, where the provider runs the control plane. What you learned in this course applies directly, but a few things differ. In this lesson, we compare the three big services, and see what is yours to manage.

• The provider runs the control plane
• Your skills apply directly
• A few things differ

Who manages what

Picture the responsibilities in layers. At the bottom, the physical data centre, always the provider's. Above it, the control plane, the A P I server, et see dee, the scheduler, and controllers. In a managed service, the provider runs, patches, backs up, and scales it, for you. Next, the worker nodes. You choose their sizes, and counts, and sometimes the provider can manage them too, or even hide them completely. Above that, your applications, your configuration, your security rules, and your costs. They are always yours.

1. Data centre and hardwarealways the provider
2. Control planemanaged by the provider
3. Worker nodesshared, or fully managed
4. Your apps, config, security, costalways yours

The three big services

Here are the three big services. Amazon E K S integrates with Amazon identity roles, load balancers, and storage, and gives you nodes, as managed node groups, or as serverless Fargate. Google G K E is known for being the most polished, with an Autopilot mode, where Google manages the nodes, and you pay per pod. Microsoft A K S integrates with Azure identity, and developer tools, and offers a free control plane tier. All three use standard Kubernetes, so your manifests, and Helm charts, work on any of them, with small differences in storage classes, load balancers, and identity.

What changes in the cloud

A few things change in the cloud. Load balancer services create real cloud load balancers, with an address, and a bill. Storage classes map to cloud disks, with different speeds, and prices. Identity is different. Pods can assume cloud roles, without secrets, which is the best practice. Networking may use the cloud's own network plugin, so pod addresses come from your virtual network. And upgrades are scheduled, and often automatic, so you must keep your manifests current. Read the provider's guide for each, once, and everything else remains familiar.

Summary