Kubernetes In Docker (KIND)

Kubernetes, often abbreviated as K8s, is an open-source container orchestration platform designed to automate the deployment, scaling, and management of containerized applications. Originally developed by Google, it is now maintained by the Cloud Native Computing Foundation (CNCF).

Kubernetes IN Docker (KIND) is a tool that allows you to run Kubernetes clusters in Docker containers. It's primarily used for testing and development purposes, enabling developers to create local Kubernetes environments quickly and efficiently.

KIND lets developers set up a mini Kubernetes cluster right on their desktop using Docker. This makes it easy to test and develop applications in a Kubernetes environment without needing access to a real server or cloud infrastructure.

The following is a list of quick steps to run KIND on Windows platform.

[1] Install choco

run powershell command:

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

[2] install kind via choco

choco install kind

outcome:

[4] install kubectl via choco

kubectl is a command-line tool used to manage Kubernetes clusters. It allows users to interact with the Kubernetes API server to perform various operations such as deploying applications, managing cluster resources, viewing logs, and troubleshooting issues.

choco install kubernetes-cli

[3] Create cluster

kind create cluster

outcome:

[4] Get cluster info

kubectl cluster-info --context kind-kind

outcome:

[5] Get nodes

kubectl get nodes

outcome:

[6] Viewing via web browser

[6.1] Accesing default port

View url https://127.0.0.1:2562/

outcome (error):

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {},
  "code": 403
}

reason:

The error message you're encountering indicates that you're trying to access a Kubernetes API endpoint without proper authentication. By default, KIND clusters do not allow unauthenticated access, which is why you see the 403 Forbidden error.

[6.2] Create web proxy

run command:

kubectl proxy

outcome:

View url https://127.0.0.1:2562/ again.

outcome:

{
  "kind": "APIResourceList",
  "groupVersion": "v1",
  "resources": [
    {
      "name": "bindings",
      "singularName": "binding",
      "namespaced": true,
      "kind": "Binding",
      "verbs": [
        "create"
      ]
    },
    {
      "name": "componentstatuses",
      "singularName": "componentstatus",
      "namespaced": false,
      "kind": "ComponentStatus",
      "verbs": [
        "get",
        "list"
      ],
      "shortNames": [
        "cs"
      ]
…

The response you're seeing is the Kubernetes API returning a list of available resources. This means your kubectl proxy is working correctly, and you are able to query the Kubernetes API.

[6.3] some url accesses:

http://127.0.0.1:8001/api/v1/pods

http://127.0.0.1:8001/api/v1/services

http://127.0.0.1:8001/api/v1/namespaces

but normally we can access them via kubectl cli command:

kubectl get pods
kubectl get services
kubectl get namespaces

example:

note:

If you're running kubectl get pods and getting "no resources found," it usually means that there are currently no pods runnin

[7] Using web dashboard

[7.1] Install

run command:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.5.1/aio/deploy/recommended.yaml

outcome:

[7.2] Get dashboard

kubectl get pods -n kubernetes-dashboard

outcome:

[7.3] Open dashboard

run command:

kubectl proxy

and then view http://127.0.0.1:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

outcome:

you need to enter a valid token

run command to create token:

kubectl create token temp-admin -n kubernetes-dashboard

outcome:

enter the token and click the button sign in.

outcome:

Discussion: how does KIND differ from MiniKube?

Minikube and KIND (Kubernetes IN Docker) are both tools for running local Kubernetes clusters, but they have different approaches and use cases. Here are the key differences:

Minikube:

  1. Environment:

    • Runs a single-node Kubernetes cluster in a virtual machine (VM) or a container, depending on the driver you choose (like VirtualBox, Docker, or others).
  2. Setup:

    • Requires more resources, as it creates a VM or container that simulates a full Kubernetes environment.
  3. Features:

    • Offers additional features like built-in addons (e.g., metrics server, dashboard) that can be easily enabled or disabled.

    • Supports multi-node clusters, but primarily designed for single-node setups.

  4. Use Cases:

    • Ideal for users who want to test Kubernetes features in a more complete environment or need addons for specific functionalities.

KIND:

  1. Environment:

    • Runs Kubernetes clusters in Docker containers, which means it doesn’t require a VM layer.
  2. Setup:

    • Lightweight and faster to start, as it directly uses Docker without the overhead of a VM.

    • More suitable for CI/CD pipelines due to its quick setup and teardown capabilities.

  3. Features:

    • Focused on simplicity and speed, with fewer built-in features compared to Minikube.

    • Best for testing Kubernetes applications and configurations quickly.

  4. Use Cases:

    • Great for developers needing to test applications in Kubernetes or for automated testing in CI environments.

Summary:

  • Minikube is ideal for users wanting a more complete Kubernetes experience with additional features and addons, usually running in a VM.

  • KIND is lightweight and fast, making it perfect for development and testing, especially in CI/CD environments, using Docker containers directly.