Disaster Project

After a first article (Kubernetes Dashboards 1) on generalist Kubernetes Dashboards, this article focuses on those dashboards that are geared to certain needs.

Specifically we will focus on three dashboards that go to three needs: Look into the status of a large number of pods, see the relationships between objects and get an overview on a platform kubernetes on docker.

Kubernetes Dashboards

Kube-ops-view

With 1200 stars in Github, this project presents a very basic dashboard thinking of large server farms, where we have an important volume of pods that we need to review at a glance.

How to install

We create a namespace to install kube-ops-view:

kubectl create namespace kube-ops-view --dry-run -o yaml | kubectl apply -f -

We create a system account with administrator capabilities

kubectl create -n kube-ops-view serviceaccount kube-ops-view-sa --dry-run -o yaml | kubectl apply -f -
kubectl create clusterrolebinding kube-ops-view-sa --clusterrole=cluster-admin --serviceaccount=kube-ops-view:kube-ops-view-sa --dry-run -o yaml | kubectl apply -f -

And we do execution of a deployment together with a service for its publication

cat <<EOF |kubectl apply -n kube-ops-view -f -
 ---
apiVersion: v1
kind: Service
metadata:
  name: kube-ops-view
  namespace: kube-ops-view
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: kube-ops-view
  type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: kube-ops-view
  name: kube-ops-view
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kube-ops-view
  template:
    metadata:
      labels:
        app: kube-ops-view
    spec:
      serviceAccountName: kube-ops-view-sa
      containers:
      - image: hjacobs/kube-ops-view:0.11
        name: kube-ops-view
        ports:
        - containerPort: 8080

Despite being a single service (without authentication, important), its container is similar in size to the solutions shown before:

docker.io/hjacobs/kube-ops-view                   0.11                fd70a70b6d70d       40.8MB

So its deployment must be fast.

Features

Its interface, shown in the following figure is minimal:

Without options to enter the objects or to edit, the information appears when passing over the “boxes”.

Easy to use

Clearly limited for those who start in Kubernetes or want additional information about objects, but very useful for those who want to visualize large volumes of pods.… Read the rest “Kubernetes dashboards 2”

Kubernetes with External DNS, MetalLB and Traefik will help us to have web applications (in a microservice environment or not) be published, since the basic requirements are to resolve the name of the computer and the web path that leads to the DNS. application.

The big map

After the steps taken in K3s: Simplify Kubernetes and Helm v3 to deploy PowerDNS over Kubernetes we are going to shape a more complete Kubernetes solution so that you can publish services under your own domain and route and be accessible from outside. Always using the minimum resources in this task.

MetalLB

MetalLB will allow us to emulate the power of the load balancers of the Cloud providers, the requirements of this solution are Kubernetes version 1.13 or higher, and must be no other network balancer operating and that the network controller is supported in the list indicated in https://metallb.universe.tf/installation/network-addons/, we must bear in mind that K3s includes flannel that is supported and that in the case of others like Weave some modifications are required.

To install MetalLB you only need to apply the “yaml” file that deploy all the elements:

$ sudo kubectl apply -f "https://raw.githubusercontent.com/danderson/metallb/master/manifests/metallb.yaml"

And to activate MetalLB we must create a configuration (file pool.xml) that contains something like this:

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: my-ip-space
      protocol: layer2
      addresses:
      - 192.168.8.240/28

When applied with k3s kubectl apply -f pool.yml will configure MetalLB so that if there are services with “loadBalancer” they use one of the IPs defined in the specified range (in this case 192.168.9.240/28).

MetalLB give us a great advantage over other types of local solutions, since it does not require the use of SDN (such as Kubernetes on VMware NSX) or specific servers for publishing (such as OpenShift, which in addition to SDN, need specific machines to publish services).… Read the rest “How to publish Kubernetes with External DNS, MetalLB and Traefik.”

In the article about PowerDNS on Docker or Podman, easy to run we leave pending its realization on Kubernetes, this is because Kubernetes service structure is much more complex than that Docker or Podman and therefore a completely different approach must be made.

Package with Helm v3

The first thing to keep in mind is package applications so that the deployment doesn’t require extensive knowledge about Kubernetes (make life easier for the user, the developer) and the second is that we can have many users on the same environment wishing to raise the same application and we can’t create a package for each one, we must to be able to reuse the package we have created.

In Kubernetes the package standard is Helm , that will allow us to manage deployments easily and be reusable by user, project, etc. The Helm package consists of:

• Chart.yaml: Where the meta information about the package itself is.
• templates: Folder where we are going to define the objects that are going to be deployed in Kubernetes, but that will have certain modifications so that they are flexible.
• values.yaml: In the objects to be deployed there will be a series of variables to be defined (eg servers to access, access codes, databases on a remote server, etc.), in this file we define the predefined values of each variable, later, the user who launches the package can adjust it.
• NOTES.txt: Is placed within “templates” this file and will contain a message about the result of the package installation, such as the IP obtained or entry URL.
• _helpers.tpl: This file that we will also find inside the “templates” folder and contains definitions of variables that we can use in the objects, such as the name of the package and will allow us to make multiple deployments of the same application in the same namespace simply by changing the deployment version name.

Kubernetes is a powerful container orchestration tool where many different objects are executed and at some point in time we will be interested in modifying.

For this, Kubernetes offers us an interesting mechanism: patch, we are going to explain how to patch and we will see that this tool is far from being enough tool as would be desirable.

Patching operations in Kubernetes

According to the Kubernetes documentation and the Kubernetes API rules, three types are defined (with –type):

Strategic

This is the type of patch that Kubernetes uses by default and is a native type, defined in the SIG. It follows the structure of the original object but indicating the changes (by default join: merge, that’s why it is known as strategic merge patch) in a yaml file. For example: if we have the following service (in service.yml file):

apiVersion: v1
kind: Service
metadata:
  labels:
    app: traefik
  name: traefik
  namespace: kube-system
spec:
  clusterIP: 10.43.122.171
  externalTrafficPolicy: Cluster
  ports:
  - name: http
    nodePort: 30200
    port: 80
    protocol: TCP
    targetPort: http
  - name: https
    nodePort: 31832
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    app: traefik
  type: LoadBalancer

We are going to use the command kubectl patch -f service.yml --type="strategic" -p "$(cat patch.yml)" --dry-run -o yaml to allow us to perform tests on objects without the danger of modifying its content in the Kubernetes cluster.

In this case, if we want this service to listen for an additional port, we will use the “merge” strategy and apply the following patch (patch.yml):

spec:
  ports:
  - name: dashboard
    port: 8080
    protocol: TCP
    targetPort: dashboard

As we can see, the patch only follows the service object as far as we want to make the change (the “ports” array) and being a “strategic merge” type change it will be added to the list as seen in the command dump:

...