One of the best ways to to learn how things work is to try and build them from scratch. That’s exactly why I decided that I should build a mini shell so I can grasp the foundational concept of how a shell works. I personally like to read “development journals” with some extra storytelling spice in them, so why not try and make one myself?

Of course, to succeed in this project I actually needed to understand what exactly is a shell? A shell is a yet so simple concept in it’s core that when you are using it you might not even care about what goes on under the hood, it just works.

Today we will deep dive into the linux utility nsenter and we will enter a kubernetes node with it, without using ssh or any other middleware.

Introduction to NSEnter

So, what is nsenter? From nsenter(1):

NAME
       nsenter - run program in different namespaces

SYNOPSIS
       nsenter [options] [program [arguments]]

DESCRIPTION
       The nsenter command executes program in the namespace(s) that are specified in the command-line options (described below). If program is not given, then "${SHELL}" is run (default: /bin/sh).

The nsenter is a handy tool for entering into any given linux namespace. As you might know, a linux namespace is a sandboxing technology used for isolating different aspects of a program. The list of namespaces are as follows, taken from namespaces(7).

You may need to set some specifications to forward custom headers, if you are using stock ingress controller for your cluster.

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: "ingress-nginx"
    app.kubernetes.io/instance: "ingress-nginx"
    app.kubernetes.io/component: "controller"
    app.kubernetes.io/part-of: "ingress-nginx"
    app.kubernetes.io/version: "1.12.3"
data:
  use-forwarded-headers: "true"
  proxy-real-ip-cidr: "10.0.0.0/8" # Replace with your trusted CIDR
  compute-full-forwarded-for: "true"
  enable-real-ip: "true"
  allow-snippet-annotations: "true"

use-forwarded-headers

If true, NGINX passes the incoming X-Forwarded-* headers to upstreams. Use this option when NGINX is behind another L7 proxy / load balancer that is setting these headers.

When starting a new project or adding significant functionality to an existing one, you’ll likely face an important question: “Which database should I use?” With hundreds of database systems available—such as MySQL, Cassandra, Redis, Memcached, and PostgreSQL—choosing the right one can be overwhelming.

To make an informed decision, it’s essential to understand how databases work and why they are designed the way they are. This is where the CAP theorem comes in. It provides a foundational framework for understanding the trade-offs between consistency, availability, and partition tolerance—key factors that influence how databases handle data in distributed systems.

One of the most useful features of Helm is the ability to store state, which allows you not only to expand charts, but also to carefully delete them, clearing away all traces of their presence… However, it’s a good idea to understand exactly how Helm stores the state, which is what we will do in this article.

Introduction

I was just interested in learning how Helm stores state. Understanding this issue is not difficult and everything is cleared in the documentation. As of Helm 3, state is kept secret by default.