mateiidavid

#!/usr/bin/lua

-- I think technically this will only work if we're on that branch?
-- gotta ReadTheFriendlyManual.
local CMD_GIT_BRANCH = 'git rev-parse --abbrev-ref HEAD'

-- Could use regex instead of basename here but I'm lazy like that
local CMD_GIT_REPO = 'git rev-parse --show-toplevel'

local PROTECTED_BRANCHES = {['main'] = true, ['master'] = true, ['add-git-hook'] = true}

mateiidavid

From 651fc60940513e6a0f620813e2d6b1dafe54e0cd Mon Sep 17 00:00:00 2001
From: Matei David <[email protected]>
Date: Tue, 21 May 2024 09:04:19 +0000
Subject: [PATCH] Patch

Signed-off-by: Matei David <[email protected]>
---
 Dockerfile | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

mateiidavid

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define assert(expr)                                                                               \
    if (!(expr)) {                                                                                 \
        printf("%s:%d %s() %s\n", __FILE__, __LINE__, __func__, #expr);                            \
        *(volatile int *)0 = 0;                                                                    \
    }

mateiidavid

What problem are we trying to solve:

Certain workloads, such as databases, rely on headless services for discovery and for network operations. Headless services behave differently to normal clusterIP services. They do not do anything special, like representing a virtual IP, they just represent a convinience by which multiple pods can be associated.

Linkerd currently supports multicluster communication through headless services. This is also known as statefulset support (since most workloads that use a headless service are deployed as StatefulSets, the resource type provides a number of different guarantees).

The problem we have is that in a lot of cases, it is cumbersome to have a lot of different headless services that need to be passed to a StatefulSet. For example, let's say we have a cluster called source. In this cluster we have a database called my-cool-database. It has a service, database-cool-service. It will be passed as a CLI value: ./my-cool-database --discover database-cool-service.

mateiidavid

#!/usr/bin/env bash

print_summary() {
  local name="${0##*/}"
  printf "Collect proxy-logs and diagnostics\n\nUsage:\n %2s ${name} --namespace name [--selector \"key=value\"] [--o /output/path]\n\n"
  printf "Examples:\n"
  printf "%2s#Collect logs and diagnostics for all pods in 'test'\n%2s${name} --namespace test\n\n"
  printf "%2s#Collect logs and diagnostics for pods with 'app=test' label\n%2s${name} --namespace test --selector \"app=test\"\n\n"
  printf "%2s#Output files in a different path\n%2s${name} --namespace 'test' --o /path/to/files\n\n"
  printf "NOTE:\n%2s*%1sFiles will be named based on the pod and will include either a '.dg' or a '.log' extension\n%2s*%1sSelector supports only one k=v pair\n\n"

mateiidavid

Linkerd CNI plugin event processing fix

Documenting a possible approach to debugging, fixing, and testing Linkerd's CNI plugin. Issue that we're dealing with is around chaining issues (#9343).

Problem statement: when a CNI plugin that runs in interface/standalone mode runs first (e.g Cilium), it will create a *.conf file. When Linkerd's CNI plugin is installed right after, it will append itself to the existing configuration file, and a new *.conflist file will be created.

The old *.conf file is not cleaned-up. Config file is elected based on alphabetical order; our current installation process will not work, since the *.conflist file will not be considered (*.conf < *.conflist so it gets picked first).

First, cluster creation

mateiidavid

#!/usr/bin/lua

--[[
  +-------------------+
  + Lua pre-push hook +
  +-------------------+

  - Prompts user to confirm remote pushes when working on a
    protected branch and pushing to a _protected_ branch.
  - Can be installed locally or globally. I usually

mateiidavid

extensions: 
  supported: 
    - description: "Viz stack for Linkerd"
      doc_link: "https://github.com/linkerd/linkerd2/"
      name: linkerd-viz
      repo_link: "https://github.com/linkerd/linkerd2/"
    - description: Multicluster
      name: linkerd-multicluster
      repo_link: "https://github.com/linkerd/linkerd2/"
  thirdParty: 

mateiidavid

Linkerd service topology tutorial

Hi, hopefully you have watched my monthly community meet-up presentation on how to use service topology in Linkerd. This is a quick guide that shows you how to set-up a kind cluster, install linkerd and then enable service topology for a service.

Prereqs:

---

At a minimum we need to have kubectl, linkerd-cli and kind installed. Click on the links to see install instructions.

mateiidavid

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
featureGates:
  EndpointSlice: true
  EndpointSliceProxying: true
  ServiceTopology: true
nodes:
  - role: control-plane
    kubeadmConfigPatches:
    - |