Skip to content

Latest commit

 

History

History
146 lines (128 loc) · 20.8 KB

README.md

File metadata and controls

146 lines (128 loc) · 20.8 KB
Raw


Networking Links

Kubernetes Networking recommended reading list.

Linux Networking

Netfilter

  • An In-Depth Guide to iptables, the Linux Firewall by supriyo-biswas
  • Benchmarking nftables: Regarding scalability, ipset is a blessing to any iptables set up. Nftables follow the path with their native implementation of sets and take the concept to a higher level by extending the list of supported data types and allowing it to be used in further applications using (verdict) maps.
  • Nftables ruleset debug/tracing: This is an equivalent of the old iptables method -J TRACE, but with some great improvements.
    • kube-proxy nftables and iptables vs a Service with 100k endpoints: Iptables performance is limited mainly by two reasons; Latency on the first packet of a connection caused by the linear search rule matching, Latency on the programming latency caused by the need to save and restore all the lines to the kernel in each transaction. The kernel community moved to nftables as replacement of iptables, with the goal of removing the existing performance bottlenecks by Antonio Ojea
  • Iptables the end of an era: Kubernetes has decided to implement a new nftables proxy by Antonio Ojea
  • Add an nftables-based kube-proxy backend: The default kube-proxy implementation on Linux is currently based on iptables. IPTables was the preferred packet filtering and processing system in the Linux kernel for many years (starting with the 2.4 kernel in 2001). However, problems with iptables led to the development of a successor, nftables, first made available in the 3.13 kernel in 2014, and growing increasingly featureful and usable as a replacement for iptables since then. Development on iptables has mostly stopped, with new features and performance improvements primarily going into nftables instead by Dan Winship.

Sockets

Linux Namespaces

Kubernetes Networking

IPVS

eBPF

IPv6

Multi-cluster

CNI

Calico

Ingress

Network Solutions Details

DNS

Routing

Service Mesh

Istio

  • Life of a Packet in Istio: Sidecar injection, init-container iptables configuration and traffic Interception in Sidecar proxy.
  • Understanding the Sidecar Injection, Traffic Intercepting & Routing Process in Istio: What is the sidecar pattern and what advantages does it have? How are the sidecar injections done in Istio? How does the sidecar proxy do transparent traffic intercepting? How is the traffic routed to upstream?
  • Tunneling egress traffic through the gateway: Make it possible to enable TCP tunneling in egress gateway. Then apps would perform standard requests that would be routed to the egress gateway, which would be responsible for tunneling received requests.
  • Tunneling egress traffic - improvements: This document proposes improvements to recently implemented tunneling destination rule. Traffic cannot be tunneled when a service specifies its protocol as HTTP, GRPC or any other than TCP or TLS (in fact they could be tunneled when routed through a gateway, but with some other problems, so it’s not recommended). The reason for this limitation is that only TcpProxy can tunnel traffic, so in case of HTTP, where the underlying listener is HttpConnectionManager, it’s not possible without redirecting traffic to an intermediary TcpProxy.
  • Dynamic setting value of TcpProxy.tunneling_config.hostname : The problem is that the tunneling_config.hostname can only be statically defined, so I can't tunnel traffic to multiple destinations having a single listener. One of the potential solutions would be to set hostname based on SNI. TLS Inspector filter provides SNI value in %REQUESTED_SERVER_NAME%, but it's not possible to overwrite Host header.
  • Tunneling HTTP traffic transparently: Sidecars don't terminate TLS traffic, so when you initiate HTTPS request from your application, you can't perform header-based routing. But you can send plain text request, perform header-based routing and then apply a DestinationRule that originates TLS.
  • Istio Creates Unnecessary Envoy Clusters: We use Istio's Sidecar CRD to limit to what external services a business service has the access. Despite that, thousands of unused Envoy clusters are created in the business service's Istio sidecar config.
  • Troubleshooting "no healthy upstream" errors in Istio service mesh: A "no healthy upstream" error can be caused by Istio, a misconfigured network device, or actual network outages. Thus, it is difficult for the mesh operations team to pinpoint the cause or even predict its occurrence, because DevOps teams may unwittingly apply an incorrect configuration.
  • How to direct outgoing traffics using HTTPS_PROXY through Egress Gateway in Service Mesh: All traffic of the client with HTTPS_PROXY would be forwarded to the external proxy through egress gateway of the Istio for accessing the external target service.
  • Istio MTLS Smartness Explained: Discuss the underlying concepts behind the Istio’s automatic mTLS.
  • Example policies to enforce mTLS between sidecar and egress gateway: The connection between sidecar and egress gateway could be: plaintext in (Istio) mTLS or TLS in (Istio) mTLS. An AuthorizationPolicy is applied on egress gateway to enforce egress access control.
  • Aeraki: Manage any layer-7 traffic in a service mesh.