Category: Series

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: We create a system account with administrator capabilities And we do execution of a deployment together with a service for its publication Despite being a single service (without authentication, important), its container is similar in size to the solutions shown before: 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. Kubeview Although with only 150 stars on github, this project focuses on representing the relationships between objects in Kubernetes. Being very interesting for demonstrations. How to install Until the Helm Chart is developed (https://github.com/benc-uk/kubeview/tree/master/deployments/helm) It is installed in the “default” namespace by installing two files: The first file includes the user account kubeview and the corresponding permissions, the second the deployment together with a service type “LoadBalancer”. The image size is small and its deployment is fast. Features Kubeview is simple and its graphic configuration makes it very interesting to teach Kubernetes or presentations. Its menu consists only of a name space selector and a window refresh time. When we select a namespace it will show us all the objects that said namespace has. In this way we can at a glance see the relationships and elements such as the IPs of publication of the services. When we select an object (for example a service) it shows descriptive information about it. Easy to use Very basic and with functions limited to training or demonstration. It has no major pretensions, which are to show the relationships between objects. Weave-Scope This interesting […]

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: And to activate MetalLB we must create a configuration (file pool.xml) that contains something like this: 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). Traefik Traefik It is a router service with multiple features such as: With K3s Traefik is automatically deployed when starting the master node, in the case of Kubernetes it will be done through Helm and for configuration we need a yaml file like the following: dashboard: enabled: “true” domain: “traefik-dashboard.DOMINIO” auth: basic: admin: $apr1$zjjGWKW4$W2JIcu4m26WzOzzESDF0W/ rbac: enabled: “true” ssl: enabled: “true” mtls: enabled: “true” optional: “true” generateTLS: “true” kubernetes: ingressEndpoint: publishedService: “kube-system/traefik” metrics: prometheus: enabled: “true” This configuration is very similar to the one that K3s deploys and we have added the dashboard where we can check the status of the routes and services configured. There are several important points: To execute the Chart with Helm 3 […]

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: Helm v3 is the stable version of Helm (at the time of writing these lines Helm goes for version v3.0.2) but it has such interesting capabilities as life cycle management or not requiring integrated services in Kubernetes to deploy packages ( to do something similar in version 2 see How to launch a Helm Chart without install Tiller, which requires a job and a launcher pod with Tiller, which represents a greater complexity). Using Helm Once we have arranged our Kubernetes cluster (see Kubernetes: Create a minimal environment for demos or K3s: Simplify Kubernetes) we proceed to download the Helm binary on the master node with: And that’s it, we don’t have to install anything and then we can install the packages that we need directly, that is, we must bear in mind that Helm v3 doesn’t automatically create namespaces because is considered that this is not a deployment task but part of infrastructure management. In the case of Powerdns, whose dependency is a mariadb database and we can optionally attach a dashboard with PowerDNS-Admin, we’ll require this type of packages, because are useful if we want customers to have their own managed DNS server by themselves. In future articles we will see that this server is also integrable with External-DNS, which will allow us to publish in PowerDNS the modifications to the Kubernetes input proxies (for example an Ingress with Traefik). To create a package with the minimum structure we do: That will create an infrastructure with the elements indicated above, such as the PowerDNS […]

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): 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): 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: But if instead of “merge” we use “replace” what we do is eliminate all the content of the subtree where we are indicating the label “$patch: replace” and instead, directly put the content of the patch. For example to change the content of the array we use the file “patch.yml”: In this example, the entire contents of “ports:” are deleted and instead the object defined after the “$patch: replace” tag is left, although the order is not important, the tag can go back and has the same effect . The result of the above is: Finally, “delete” indicated by “$patch: delete” deletes the content of the subtree, even if there are new content, it is not added. The result will be the empty spec content: Merge This type of patch is a radical change compared to “strategic” because it requires the use of JSON Merge Patch (RFC7386), it can be applied as yaml or […]