aojea

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 6.11.0 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="gcc (Debian 13.2.0-13) 13.2.0"
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=130200
CONFIG_CLANG_VERSION=0
CONFIG_AS_IS_GNU=y
CONFIG_AS_VERSION=24200

aojea

Running a Pod with a predefined MAC address

There are situation that, for reasons, you want your Pod to have a static MAC.

Since the Pod uses a veth pair, the application running inside the Pod sees the side of the veth that is on its network namespace.

Using an initContainer with enough privileges, we can change the MAC address before the application runs.

  initContainers:

aojea

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

aojea

commit 757999d6b5e3ed7d218313042eb8773d59edb44c
Author: Antonio Ojea <aojea@google.com>
Date:   Thu Jul 4 08:30:02 2024

    test local-up

diff --git a/test/integration/localup/localup_test.go b/test/integration/localup/localup_test.go
new file mode 100644
index 00000000000..93440417d39
--- /dev/null

aojea

Useful for troubleshooing network namespaces problems without having to create containers and the additional functionality

source netns.sh

netns_add ns1 192.168.0.2 192.168.0.1
netns_add ns2 192.168.0.3 192.168.0.1

ping -c 2 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.

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");