Ambassador API Gateway

This is Kubernetes-native API Gateway for controlling and managing traffic between microservices within a Kubernetes cluster. Built on top of Envoy Proxy.
It integrates with Kubernetes Service objects to route traffic to the appropriate microservices based on the service name and port.
Advatanges:
1. Supports Multiple Protocols: HTTP/1.1, HTTP/2, WebSocket, gRPC, and OpenAPI/Swagger
2. Other Functions: traffic splitting, load balancing, rate limiting, and authentication.

Authorization in kubernets

Kubernetes Controller = control loop

A Kubernetes controller is a control loop/Reconcile loop/Infinite loop that continuously watches the state of kubernets cluster and makes changes to align the actual state with your desired state.
This is similar to = File Watcher(fsnotify)
How Controllers Run (Reconciliation Loop = Infinite Loop)
1. Observe: Look at the current state of the world
2. Analyze: Compare the Current State with the Desired State
3. Act: Take corrective action to bridge the gap

Types of Controllers

1. Kubernetes Operator (Domain specific Controller)

It can manage:
1. Built-in kubernetes resources. Eg(Pods, Deployment, Node etc)
2. User created Custom Resources (CR). CRD means my specific resource(e.g., a MyDatabase resource).

while (1) { 
    if (state changed)
        Apply state 
} 

Pod Recovery Flow (Reconciliation Loop)

Method-1: User defined reconciliation loop using client-go library

hello World pod is created everytime its deleted

Method-2: Control Plane running Controller

Check Kubernetes Architecture 1st
The sequence diagram below illustrates how the control plane detects a pod failure and ensures it keeps running

Kubebuilder = framework/SDK

Work-1 (Build custom Kinds):
  While native Kubernetes gives us built-in kinds like (Service, Deployment, Pod etc).
  With Kubebuilder we can define entirely new kinds using Custom Resource Definitions (CRDs) tailored to our applications (such as kind: Database, kind: RedisCluster, or kind: AppDeployment).
  Why would someone create a new kind?
  - Built-in Kubernetes kinds are generic. They don't know anything about your specific application, database, or business logic
  - We want higher-level abstraction: Instead of forcing developers to manually write 5 different manifests eg: (Deployment, Service, ConfigMap, PersistentVolumeClaim, Secret) every time they want to deploy a database, you create a single kind (kind: MyDatabase) that handles all of that under the hood.
  - If a database crashes or needs a backup, native Kubernetes doesn't know how to do a database backup. By creating a custom kind and pairing it with a controller (written via Kubebuilder), your cluster gains the intelligence to automatically perform specialized tasks like failovers, schema migrations, and backups.
  Code Example: Creating a new kind = Greetings

Work-2 (Talk to the API server, through controller-runtime library to keep kind alive)
  Code Example: Kubebuilder plugs into a Kubernetes controller and keeps newly created Kind:Greetings Up and Live

karpenter (Cluster Autoscalar)

HPA scales Pods(50 → 300 pods)
karpenter scales Kubernetes cluster(adds EC2 nodes if needed)

Namespace

Namespace divides cluster into smaller units to isolate services,volumes and manage.
Namespace contains pods.
3 predefined namespaces: Default, Kube-system(resources created by kubernets), Kube-public(reserved for future)

$ kubectl create namespace test                       //Creating new namespace
$ kubectl --namespace=test  run ngnix --image=nginx   //Deploy namespace
        

Ports

ContainerPort

Port on which application inside container is listening

HostPort

If you want to directly map a host machine port → container port, you can use hostPort
Its use is discouraged since only 1 application can take host's port, harder to scale, not load balanced

Nodeport

Client reaches host(http://1.2.3.4:8080) and traffic goes to container's(8080)
            |------------------ Host (1.2.3.4)--------------------------------|
            |                                                                 |
            | 8080 ----> NodePort(30080) -----> Pod(container(service8080))   |
            |                                                                 |
            |-----------------------------------------------------------------|
      

nodePort is mapped to targetPort internally.
Why NodePort? 2 Applications can use same internal ports. Eg: App1 uses 8080 & App2 uses 8080. When traffic arrives kubernets will send traffic to both containers.

$ cat templates/deployment.yaml
spec:
  containers:
    - name: service1
      image: yourimage
      ports:
        - containerPort: 8080         // Port on which container is listening
          name: port-8080

$ cat templates/service.yaml
apiVersion: v1
kind: Service
metadata:
    name: service1
spec:
    selector:
    app: service1        # must match your Deployment labels
    type: NodePort         <---------
    ports:
    - port: 8080         # Service port (cluster internal)
      targetPort: 8080   # Container port inside Pod
      nodePort: 30080    # External Node port (optional; else auto-assign)

// Create firewall rule to send any packet coming to 8080 on this host → redirect to port 30080 
$ sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 30080
            

PVC(Persistant Volume Claims)

Types of PVC

Service

This is kubernets Networking objects
Service is Networking abstraction which provides stable network access to pods.
service does not run inside containers, these are k8s objects. Each service routes the traffic to 1 or more POD
Service provides: Load balancing, service discovery, stable endpoints

Terms

Custom Resource Definition (CRD)

Resources which are created by user. Controller manages Custom Resources (CR).