aojea

kube-proxy nftables and iptables vs a Service with 100k endpoints

Background

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. Kubernetes has decided to implement a new nftables proxy because of this and another reasons explained in more detail in the corresponding KEP and during the Kubernetes Contributor Summit in Chicago 2023 on the session [Iptables, end of

aojea

1. Deploy the backends with the number of replicas we desire (we can always use kubectl later to scale up or down)

kubectl apply -f backend.yaml

2. I recommend use the ClusterIP the Service and not depend on DNS since we just want to test the IP traffic

kubectl get service

aojea

Kubernetes DNS at scale

It seems that is a common practice in HPC and AI/ML environments that use MPI applications to populate a hosts files with all the nodes on the cluster and copy it over all the nodes, ref https://help.ubuntu.com/community/MpichCluster

It is my observation that in Kubernetes, Headless Services are used to implement this Service Discovery This is very handy because it allows to reference a pod by hostname without having to copy over a generace /etc/hosts.

There must also be an A record of the following form for each ready endpoint with hostname of and IPv4 address . If there are multiple IPv4 addresses for a given hostname, then there must be one such A record returned for each IP.

aojea

# See for more options https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-ethtool
  namespace: kube-system
  labels:
    k8s-app: node-ethtool-config
spec:
  selector:

aojea

diff --git a/cmd/genfeatures/genfeatures.go b/cmd/genfeatures/genfeatures.go
new file mode 100644
index 00000000000..953305e2715
--- /dev/null
+++ b/cmd/genfeatures/genfeatures.go
@@ -0,0 +1,43 @@
+/*
+Copyright 2023 The Kubernetes Authors.
+
+Licensed under the Apache License, Version 2.0 (the "License");

aojea

apiVersion: apps/v1
kind: Deployment
metadata:
  name: server-deployment
  labels:
    app: MyApp
spec:
  replicas: 2
  selector:
    matchLabels:

aojea

KEP-1880: Multiple Service CIDRs

Introduction

KEP-1880 allows to configure via API objects the ServiceCIDRs assigned to Kubernetes clusters

This demo is using kind and based on the existing PR kubernetes/kubernetes#116516

A live demo was done in the SIG-Network meeting on Oct 12th 2023 https://youtube.com/playlist?list=PL69nYSiGNLP2E8vmnqo5MwPOY25sDWIxb&si=vTNuT7EBFujoQOce

aojea

kubectl get pods -A -o wide | grep dns
kube-system   kube-dns-5bfd847c64-bkkhf                           4/4     Running   0             80m   10.108.0.5    gke-vanilla-default-pool-ddebe65c-pkzw   <none>           <none>

kubectl debug -n kube-system -it kube-dns-5bfd847c64-bkkhf --image=busybox:1.28 --target=dnsmasq
Targeting container "dnsmasq". If you don't see processes from this container it may be because the container runtime doesn't support this feature.
Defaulting debug container name to debugger-qz6cb.
If you don't see a command prompt, try pressing enter.

aojea

apiVersion: v1
kind: Pod
metadata:
  name: job1
  labels:
    job-name: "job1"
    job-index: "0"
spec:
  hostNetwork: true
  containers:

aojea

apiVersion: apps/v1
kind: Deployment
metadata:
  name: netperf-server
  labels:
    app: netperf-server
spec:
  replicas: 1
  selector:
    matchLabels: