Kubernetes Networking Contd
Layer 7 Ingress: Ingress Controller
- Ingress is k8s specific Layer & HTTP Load Balancer which is accesible externally Refer Here
- Ingress controller is required to fulfil ingress Refer Here
- Sample Implementation
Evaluate Some ingress Controllers
-
Things to be considered
- Protocol Support: gRPC integration, Web Socket, TCP/UDP, HTTPS
- Commercial Support
- Advanced features:
- JWT/OAUTH2 authentications, circuit breakers etc
- API Gateway features
- Traffic Distribution
- Breif list of ingress controller options
| Name | Commercial Support | Engine | Protocol Supported | SSL Termination |
|---|---|---|---|---|
| Ambassador ingress Controller | Yes | Envoy | gRPC, HTTP/2, WebSockets | Yes |
| Community Ingress Nginx | No | Nginx | gRPC, HTTP/2, WebSockets | Yes |
| Ngingx Inc Ingress | Yes | Nginx | gRPC, HTTP/2, WebSockets | Yes |
| HA Proxy Ingress | Yes | HAProxy | gRPC, HTTP/2, WebSockets | Yes |
| Istio Ingress | No | Envoy | HTTP, HTTPS, gRPC, HTTP/2 | Yes |
| Traefik Kuberntes Ingress | Yes | TraefiK | gRPC, HTTP/2, WebSockets | Yes |
Managed Kubernetes
- Managed Kuberentes or kubernetes as a service are offered by CSP (Cloud Service Providers) like AWS, Azure, GCP .
- The basic idea is CSP’s will manage the control plane and if we dive deeper, Managed K8s gives us option to
- use CNI plugin which is cloud aware i.e. k8s knows about cloud networking
- use CSI to create storages automatically on cloud
- We will be dealing with k8s where it is aware of creating
- load balancers (layer 4 and layer 7)
- storage (for volumes)
- node autoscaling (we can scale nodes as well in addition to pods)
- upgrading clusters
- inbuilt monitioring etc
- For this they charge hourly for control plane and nodes are charge as normal virtual machines
- There are options with serverless as well where you will be charged for k8s resources not for nodes
AWS Networking breifly
- Regions and Availabiltiy Zones
- AWS Networking Elements
Amazon Elastic Kubernetes Service (EKS)
- This is managed k8s service which allows developers, cluster admins adn network admins to quickly deploy a production grade k8s cluster
- EKS now supports even on-premises deployments of k8s with EKS Anywhere
- EKS Supports serverless with EKS Fargate.
- EKS Clusters were deployed traditionally using AWS CLI/Console
eksctlis a commandline developed by WeaveWorks and this is byfar the easiest way to deploy and run eks- Like any Managed kuberentes, AWS manages control plane and we have options for Worker Nodes(Nodes)
- EKS Nodes (Worker Nodes) Come in 3 flavors
- Managed Node Group
- Self Managed Node Group
- Fargate
- Managed Node Group
- EKS Managed Node groups create and manage EC2 instances for you
- All managed nodes are provisioned as part of EC2 Auto Scaling Group (ASG) that’s managed by Amazon EKS
- Self Managed Node Group:
- EKS runs in your account and connect to your cluster’s control plane via API Endpoint
- You can deploy nodes into node group (Which is collection of EC2 instances that are deployed into an EC2 ASG)
- All instances in a node group must
- be of same instance type (Sizes are same)
- be running the same AMI (Amazon Machine Image)
- be using same EKS node IAM role
-
Fargate:
- Each Pod running on Fargate has its own isolation boundry and we can’t share this with other pods
-
EKS Networking Modes: There are 3 ways to configure cluster control traffic and k8s API Endpoint
- Public-only:
- Everything runs in a public subnet including worker nodes
- Private-only:
- Runs soley in private subnet & k8s cannot create internet facing Load Balancers
- Mixed
- Combination of Private and public
- Public-only:
- EKS Communication Path
