K3d

After my previous posts related to Argo CD (one about argocd-autopilot and another with some usage examples) I started to look into Kluctl (I also plan to review Flux, but I’m more interested on the kluctl approach right now). While reading an entry on the project blog about Cluster API somehow I ended up on the vCluster site and decided to give it a try, as it can be a valid way of providing developers with on demand clusters for debugging or run CI/CD tests before deploying things on common clusters or even to have multiple debugging virtual clusters on a local machine with only one of them running at any given time. On this post I will deploy a vcluster using the k3d_argocd kubernetes cluster (the one we created on the posts about argocd) as the host and will show how to: use its ingress (in our case traefik) to access the API of the virtual one (removes the need of having to use the vcluster connect command to access it with kubectl),publish the ingress objects deployed on the virtual cluster on the host ingress, anduse the sealed-secrets of the host cluster to manage the virtual cluster secrets....

For a long time I’ve been wanting to try GitOps tools, but I haven’t had the chance to try them for real on the projects I was working on. As now I have some spare time I’ve decided I’m going to play a little with Argo CD, Flux and Kluctl to test them and be able to use one of them in a real project in the future if it looks appropriate. On this post I will use Argo-CD Autopilot to install argocd on a k3d local cluster installed using OpenTofu to test the autopilot approach of managing argocd and test the tool (as it manages argocd using a git repository it can be used to test argocd as well). Installing tools locally with arkadeRecently I’ve been using the arkade tool to install kubernetes related applications on Linux servers and containers, I usually get the applications with it and install them on the /usr/local/bin folder. For this post I’ve created a simple script that checks if the tools I’ll be using are available and installs them on the $HOME/.arkade/bin folder if missing (I’m assuming that docker is already available, as it is not installable with arkade): #!/bin/sh # TOOLS LIST ARKADE_APPS="argocd argocd-autopilot k3d kubectl sops tofu" # Add the arkade binary directory to the path if missing case ":${PATH}:" in *:"${HOME}/.arkade/bin":*) ;; *) export PATH="${PATH}:${HOME}/.arkade/bin" ;; esac # Install or update arkade if command -v arkade >/dev/null; then echo "Trying to update the arkade application" sudo arkade update else echo "Installing the arkade application" curl -sLS https://get.arkade.dev | sudo sh fi echo "" echo "Installing tools with arkade" echo "" for app in $ARKADE_APPS; do app_path="$(command -v $app)" || true if [ "$app_path" ]; then echo "The application '$app' already available on '$app_path'" else arkade get "$app" fi done cat <<EOF Add the ~/.arkade/bin directory to your PATH if tools have been installed there EOF...

This post describes how to deploy cilium (and hubble) using docker on a Linux system with k3d or kind to test it as CNI and Service Mesh. I wrote some scripts to do a local installation and evaluate cilium to use it at work (in fact we are using cilium on an EKS cluster now), but I thought it would be a good idea to share my original scripts in this blog just in case they are useful to somebody, at least for playing a little with the technology. LinksAs there is no point on explaining here all the concepts related to cilium I’m providing some links for the reader interested on reading about it: What is CNI?What is Cilium?What is eBPF?What is Hubble?Why use Cilium with Kubernetes?...