![IPv4 and IPv6 Support
• The CNI controls Pod addressing (can be IPv4/6/dual/etc)
• Kubernetes Controls ClusterIP addressing:
• IPv4-only GA in K8s v1.0
• Only IPv4 Services
• IPv6-only GA in K8s v1.18
• If enabled, only IPv6 Services
• Either IPv4/IPv6 in K8s 1.20
• Either IPv4 or IPv6 services in the same cluster
• Dual-stack IPv4/IPv6 GA in K8s 1.23 [two ranges must be supplied]
• Services ipFamilyPolicy can be set to:
• SingleStack – uses the first configured service cluster IP range
• PreferDualStack – allows you to optionally define a single ClusterIP
• RequireDualStack – requires you to define IPv4 & 6 if you define ClusterIP](https://image.slidesharecdn.com/kubernetes-networking-101-240405063852-9b7f31bf/85/Kubernetes-Networking-101-kubecon-EU-2022-16-320.jpg)
Kubernetes Networking 101 kubecon EU 2022
- 2. Presenter and Dutch Uncles • @RandyAbernethy • Managing Partner at RX-M • CNCF Ambassador • Cloud Native Uncles • Chris • “kubectl said what?” at 16:00 today!! • Iliyan • Valentin • Tutorial Lab Doc: • https://github.com/ RX-M/kubecon-eu-2022/ net101.md @rxmllc Linkedin.com/company/rx-m-llc https://www.youtube.com/channel/UCyFZuVfrRposGJ86mkWcF_Q
- 3. • Concepts and Projects Explored: 1. Container Networking • CNI and Cilium 2. Kubernetes Services • Kubernetes 3. Kubernetes DNS • CoreDNS 4. Outside Access • Emissary, Envoy and MetalLB 5. Service Mesh • Linkerd
- 5. Container Networking • There’s no such thing as a Container • There are just processes running on Linux • However, we can isolate a process using Linux namespaces • A network namespace gives a process and its children a virtual ip stack • Network namespaces include private copies of: • Interfaces • loopback • eth0 • Routes • IP Tables • And so on Host if Container if
- 6. Pod Pod Architecture • Running a container under Docker places that container in its own private network namespace by default • Kubernetes collects sets of containers together in Pods • Pods are atomic in Kubernetes: • Scheduled as a unit • Scaled as a unit • Terminated as a unit • All the containers in a Pod share the same network namespace Host if Container if Container
- 7. Pod Networking • Components of distributed applications need to communicate • When we deploy services in pods, the pods need a network • We don’t really care if the pods are on the same machine or different machines, we just care that they can talk Pod Container Container Pod Container if Container if
- 8. CNI • Kubernetes relies on three key plugins for core functionality: • CRI – Container runtime interface • CNI – Container networking interface • CSI – Container storage interface • CNI is a specification that allows systems like Kubernetes to integrate with software defined networking (SDN) solutions • CNI plugins provide: • Pod network wiring • Pod IP addresses • Network policy implementation • Potentially much more
- 9. Cilium • Cilium is an incubating CNCF project • CNI compliant • Provides Pod Networking features with the help of Linux eBPF
- 10. Cilium CNI • CNI plugins are responsible for configuring a pod’s network • Interfaces, ip addresses, routes and so on • Configuration external to the pod necessary to support intrapod networking Pod Container Container Pod Container if Container if Host if Host if Cilium Cilium eBPF eBPF
- 11. Lab Step 1 – Pod Networking ssh to your lab system Install a Kubernetes cluster Install the Cilium CNI plugin Explore the Pod network
- 13. ClusterIP
- 14. Cluster IP Implementation • kube-proxy • User mode • IPTables • IPVS • CNI Plugin • User mode • eBPF • Other approaches and combinations
- 15. Independent Address Spaces • A Kubernetes solution requires several non overlapping address spaces • HostIP (node) Range – managed by IT or your Cloud • ClusterIP Range – configured when installing K8s • PodIP Range – configured when installing your CNI plugin
- 16. IPv4 and IPv6 Support • The CNI controls Pod addressing (can be IPv4/6/dual/etc) • Kubernetes Controls ClusterIP addressing: • IPv4-only GA in K8s v1.0 • Only IPv4 Services • IPv6-only GA in K8s v1.18 • If enabled, only IPv6 Services • Either IPv4/IPv6 in K8s 1.20 • Either IPv4 or IPv6 services in the same cluster • Dual-stack IPv4/IPv6 GA in K8s 1.23 [two ranges must be supplied] • Services ipFamilyPolicy can be set to: • SingleStack – uses the first configured service cluster IP range • PreferDualStack – allows you to optionally define a single ClusterIP • RequireDualStack – requires you to define IPv4 & 6 if you define ClusterIP
- 17. Specifying a Service • Services are a resource Kind • In the Core group at maturity v1 • Like all resources they require a name in the metadata • Services have: • Ports to forward • EndPoints to forward to • Selectors identify pods to generate endpoints from
- 18. Endpoints • Selectors automatically generate EndPoints for services • EndPoints can be created manually as well
- 19. Types of Services • Headless (special case of ClusterIP) • Supports name resolution but not forwarding • ClusterIP • For load balanced intra-cluster service communications • NodePort • For external service access via a universal port • LoadBalancer • Uses a plugin to enable an external load balancer • ExternalName • Aliases this service to the specified externalName
- 20. Lab Step 2 - Services Create a Deployment Create a ClusterIP Service Figure out how it works
- 22. DNS in Kubernetes • Pod Container Filesystem hacks: • /etc/resolv.conf • /etc/hostname • /etc/hosts • CoreDNS • Deployment (ReplicaSet, 2 Pods) • AutoScaler in some distros • Service • 10.96.0.10
- 23. Service Name Resolution • myservice.mynamespace.svc.cluster.local • myservice – the service name • mynamespace – the namespace • svc – the directory for services • cluster.local – the cluster suffix set when installing the cluster • Realistic example: • web.production.svc.k8s54.rx-m.com • Resolves to ClusterIP
- 24. Headless Services • Used for StatefulSets where loadbalancing does not make sense • You need to talk to who you need to talk to, pods are not replicas • Services with no ClusterIP are Headless • Resolving the Service name produces the list of endpoints for all pods in the service • You can also resolve a specific pod by ordinal • redis-0.redis.datans.svc.cluster.local • redis-1.redis.datans.svc.cluster.local • redis-2.redis.datans.svc.cluster.local • …
- 25. Overriding Kubelet DNS config • Default resolv.conf settings can be overridden in Pod specs • Nameservers • Searches • Options
- 26. Lab Step 3 - DNS Work with DNS Create a Headless Service Use Headless DNS
- 28. Outside Access • How can we reach services inside the cluster from outside the cluster? • HostPort – Pod feature that forwards a port from the host • NodePort – Service type that adds a NodePort forwarded on every node • LoadBalancer – Service type, calls a plugin to create an external load balancer • Ingress – Kubernetes framework for HTTP/HTTPS proxying • Gateway – Like ingress but more sophisticated • Almost all schemes for inbound cluster access depend on either host ports or node ports
- 29. HostPort • Pods can define host ports • Maps a port on the worker node interface to the container interface port • Useful for cluster admins • Typically in combination with DaemonSets • Not good for applications • Deployments create pods that are scheduled, how do we know the port will be open on a given machine? • You have to know where the pod lands to reach it
- 30. NodePort • Similar to host port in that it maps a port on the host • Unlike a host port, the service is assigned a unique high number port from an admin defined range • The NodePort is forwarded on every node in the cluster to the service • NodePort services also have all of the features of a ClusterIP service
- 31. LoadBalancer • LoadBalancer services provision an external load balancer through a cluster plugin • Cloud Solutions • AWS Elastic Load Balancer • Azure Load Balancer • GCP Network Load Balancer • On Prem Solutions • MetalLB • Netris • KubeVIP • Avi (VMware) • F5 • Citrix ADC • LoadBalancer services also have all of the features of a NodePort service
- 32. Ingress • A Kubernetes framework • Kubernetes defines the Ingress resource type • HTTP/HTTPS only • An ingress controller must be installed to implement Ingress resource functionality
- 33. Gateway • Not a Kubernetes thing • Often an Ingress Controller on steroids • Common features: • Advanced Security and Auth features • Sophisticated routing and load balancing • Support for other protocols • gRPC • SCTP • UDP • TCP • Apache Thrift • Protocol translation and upgrade • Uses CRDs for config
- 34. Lab Step 4 NodePort Services Ingress Gateways
- 36. Service Mesh Functionality • A Service Mesh can implement cross cutting concerns that are desired by all of your service • mTLS • Communications Metrics • Communications Policy • Traces • Fault Injection/Chaos support • Advanced Traffic Management • A Service Mesh can also simplify cross cluster communications
- 37. Types of Service Mesh • Proxy Based • Implemented using the ambassador pattern • Most common and most tested • eBPF Based • Bleeding edge • Promises performance benefits but includes some downsides • Library Based • Implemented in the app process by a library • e.g. gRPC • New, fast but requires all apps to use “the library”