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

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
• eksctl is 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
• EKS Communication Path