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

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 <<a-role,Role,Role Binding>> 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

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

Type Description
Config PVC Store configuration files for the container(json, yaml, config). mounted at /etc/process-name inside container. Multiple pods can read
Data PVC Store application data,logs,database. Mounted at /var/lib/process-name inside container. Only 1 pod can write
Shared-Data PVC To transfer files between containers. Mounted at /shared/data inside container. All containers can read/write

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