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.

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
            

Authorization in kubernets

Name Description
1. Service Token Each pod has a associated service account. Each service account has a service token. This service account token is mounted as a file in the pod's filesystem. The default path is `/var/run/secrets/kubernetes.io/serviceaccount/token`.
Usage of service token? if service want to communicate/access resources of other services, then this service will present the service token to API-server and API server will authorize the service.
API server will check <> of service(whether service is allowed to access other service or not).
Can be used Only within cluster
2. Istio Authorization Poliy Can be used across cluster