alexeldeib

# for context, this is a 22.04 hetzner machine upgraded from 20.04 with maybe a kernel I rebuilt (?) I forgot.
root@Ubuntu-2004-focal-64-minimal ~ # cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.2 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"

alexeldeib

{
    "aks-cblmariner-v1": {
        "ResourceGroup": "AKS-CBLMariner",
        "Gallery": "AKSCBLMariner",
        "Definition": "V1",
        "Version": "202305.15.0",
        "SubscriptionID": "109a5e88-712a-48ae-9078-9ca8b3c81345"
    },
    "aks-cblmariner-v2": {
        "ResourceGroup": "AKS-CBLMariner",

alexeldeib

#!/usr/bin/env bash
retrycmd_if_failure() {
    retries=$1; wait_sleep=$2; timeout=$3; shift && shift && shift
    for i in $(seq 1 $retries); do
        timeout $timeout "${@}" && break || \
        if [ $i -eq $retries ]; then
            echo Executed \"$@\" $i times;
            return 1
        else
            sleep $wait_sleep

alexeldeib

---
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: wasmtime-spin-v0-3-0
handler: "spin-v0-3-0"
scheduling:
  nodeSelector:
    "kubernetes.azure.com/spin-v0-3-0": "true"
---

alexeldeib

Usage

Assuming you already have a usable kubeconfig with sufficient privileges:

KUBE_CA="$(kubectl -n kube-public get cm kube-root-ca.crt -o jsonpath="{.data.ca\.crt}" | base64 -w0)"
FQDN="$(kubectl config view --minify --output jsonpath='{.clusters[0].cluster.server}')"
TOKEN="$(kubeadm token create)"

sed -i "s|KUBE_CA_CERT_PLACE_HOLDER|${KUBE_CA}|g" ./bootstrap.sh

alexeldeib

package main

import (
	"context"
	"fmt"
	"log"
	"os"
	"time"

	"github.com/containerd/containerd"

alexeldeib

Q: Can you explain the flow of a packet from a user through a load balancer to a linux machine across a bridge interface to a container veth in a separate network namespace?

A: Yes, I can explain the flow of a packet from a user through a load balancer to a Linux machine across a bridge interface to a container veth in a separate network namespace. Here's a step-by-step explanation of the process:

1. User sends a packet: A user (client) initiates a connection to a service, typically by sending a request to a specific IP address and port number. The packet contains source and destination IP addresses and port numbers.
2. Load balancer: The request reaches a load balancer, which is responsible for distributing incoming network traffic across multiple servers to ensure that no single server is overwhelmed with too much traffic. The load balancer uses algorithms like round-robin, least connections, or other custom rules to determine which server should handle the request. It then forwards the packet to the

alexeldeib

admin:
  access_log_path: /tmp/admin_access.log
  address:
    socket_address:
      address: 127.0.0.1
      protocol: TCP
      port_value: 9901
static_resources:
  listeners:
  - name: listener_0

alexeldeib

#!/usr/bin/env bash

die() { echo "$*" 1>&2 ; exit 1; }

if [ -z "${API_SERVER_NAME}" ]; then
  die "API_SERVER_NAME must contain Kubernetes API server FQDN for node join."
fi

if [ -z "${TLS_BOOTSTRAP_TOKEN}" ]; then
  die "TLS_BOOTSTRAP_TOKEN must TLS bootstrap token for node join."

alexeldeib

syntax = "proto3";

package agentbaker.v1;

// illustrative division only
message Configuration {
  // System Configuration
  string api_server_endpoint = 1;
  string cluster_certificate_authority = 2;