Sujith's Library

Appearance

Deploying to the Cloud: Managed Kubernetes ​

You have built your Docker images, tested them in CI, and pushed them to a registry. Now it is time to run them in production.

While you can install Kubernetes on your own servers (using tools like kubeadm), this is complex and requires significant operational overhead (managing etcd backups, control plane upgrades, security patching).

For most teams, the standard answer is Managed Kubernetes.

1. What is Managed Kubernetes? ​

Cloud providers offer "Kubernetes as a Service."

  • They manage the Control Plane: The API server, etcd, and scheduler are managed by the cloud provider. They handle upgrades, scaling, and availability. You usually pay an hourly fee for this.

  • You manage the Worker Nodes: You provision the virtual machines (EC2, Compute Engine) that run your pods. The cloud provider automates the joining of these nodes to the cluster.

The Big Three:

  • Amazon Elastic Kubernetes Service (EKS)

  • Google Kubernetes Engine (GKE) - Often considered the "gold standard" for ease of use.

  • Azure Kubernetes Service (AKS)

2. The General Workflow ​

Deploying to any cloud Kubernetes cluster follows the same pattern:

  1. Provision the Infrastructure: Create the cluster (VPC, Control Plane, Node Groups).

  2. Configure Access: Authenticate your local kubectl with the remote cluster.

  3. Deploy Resources: Apply your Kubernetes manifests (Deployments, Services).

  4. Expose to Internet: Create a Load Balancer to accept traffic.

3. Provisioning the Cluster (Infrastructure as Code) ​

While you can click buttons in the AWS/GCP console, Infrastructure as Code (IaC) is the DevOps best practice. Tools like Terraform or eksctl allow you to define your cluster in code.

Example: Creating a Cluster with eksctl (AWS) ​

eksctl is a CLI tool that simplifies EKS creation.

# Create a cluster with 2 worker nodes
eksctl create cluster \
  --name my-cluster \
  --region us-east-1 \
  --nodegroup-name my-nodes \
  --node-type t3.medium \
  --nodes 2

This single command provisions the VPC, subnets, IAM roles, Control Plane, and Auto Scaling Group for the nodes.

4. Authenticating kubectl ​

Once the cluster is running, you need to point your local kubectl tool at it. This involves updating your ~/.kube/config file.

AWS EKS:

aws eks update-kubeconfig --region us-east-1 --name my-cluster

Google GKE:

gcloud container clusters get-credentials my-cluster --region us-central1

Azure AKS:

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Now, when you run kubectl get nodes, you should see your cloud instances!

5. Deploying the Application ​

You can now apply the same manifests you learned about in File 17.

deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: [myregistry.com/my-app:v1.0.0](https://myregistry.com/my-app:v1.0.0)  # Your private image
        ports:
        - containerPort: 80

service.yaml (The Cloud Load Balancer): To expose your app to the internet, you use a Service of type LoadBalancer.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

Apply:

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

6. The Cloud Magic: Load Balancers ​

When you apply the Service with type: LoadBalancer, the Cloud Controller Manager kicks in.

  1. It talks to the cloud provider's API (e.g., AWS ELB or Google Cloud Load Balancing).

  2. It provisions a real, physical (or virtual) Load Balancer outside your cluster.

  3. It configures that Load Balancer to route traffic to your worker nodes on the correct NodePort.

Get the Public IP:

kubectl get services

Output:

NAME         TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)
my-service   LoadBalancer   10.0.0.1       203.0.113.5      80:30123/TCP

The EXTERNAL-IP is your public endpoint. It may take a minute to provision.

7. Handling Secrets in the Cloud ​

In File 10, we discussed secrets. In the cloud, you should integrate Kubernetes with the provider's native secret manager (AWS Secrets Manager, Google Secret Manager) using a tool like the External Secrets Operator.

This allows you to manage secrets centrally in the cloud console, and have them automatically synchronized into Kubernetes Secrets.

8. Auto-Scaling ​

One of the biggest benefits of the cloud is elasticity.

  • Horizontal Pod Autoscaler (HPA): Automatically adds more Pods when CPU usage goes high.

    kubectl autoscale deployment my-app --cpu-percent=50 --min=1 --max=10

  • Cluster Autoscaler: Automatically adds more Nodes (VMs) to your cluster when there isn't enough capacity to run your Pods. This is configured on the node pool level.