Translate / Traduci
Support Gioorgi Editorial Board
In this second article, I suggest to explore further two simple helm chart for getting a bit more inside K8s.
Loki is a horizontally-scalable, highly-available, multi-tenant log aggregation system inspired by Prometheus. It is designed to be very cost effective and easy to operate. It does not index the contents of the logs, but rather a set of labels for each log stream.
The Loki project was started at Grafana Labs in 2018, and announced at KubeCon Seattle. Loki is released under the AGPLv3 license
To install Grafana+Loki follow the instruction depicted here: the install will teach you how to use helm charts dependency too, so please take time to download the loki chart and study it
Due to COVID19 pandemic, I and my family was forced in our home.
So I revamped my 8bit computer book, with a new look and a nice search engine.
Nel 1984, dopo il successo del C/64, la Commodore lanciò sul mercato il Plus4 ed il Commdore16, due macchine quasi identiche che si differenziavano per il quantitativo di RAM a bordo e per la dotazione del software in ROM.
Il Commodore 16 idealmente doveva soppiantare il Vic20, aveva 16 KB di RAM e il Basic 3.5, notevolmente più comodo del BasicV2 della coppia Vic20, C/64.
La CPU era anche il 75% più veloce rispetto ai predecessori, ma il chip grafico era incompatibile con il C/64 e il C/16 non disponeva né di Sprite né della profondità sonora del SID:
The C16’s failure in the US market was likely due to a lack of software support, incompatibility with the C64, and lack of importance to Commodore after its competitors withdrew from the market.
Il Plus/4, la versione potenziata del C/16 che doveva soppiantare il C/64 non scalfì neppure la superficie del suo parco applicativo e delle sue solide basi; per capirlo basta guardare al comparto dei videogame: quasi tutti i giochi erano pensati per il C/16 e quindi sfruttavano solo 16Kb di RAM, ignorando il fatto che il Plus/4 aveva la medesima memoria del C/64.
Infine la scelta di cambiare tutti gli attacchi (forse per costringere al riacquisto delle periferiche) fu una mossa infelice.
Fu un peccato perché il C/16, magari con 64kKB di RAM e le periferiche compatibili, poteva fare la differenza.
Ultimamente ci ho giochicchiato con l’emulatore VICE e se vi piace il retro computing, fateci una capatina: abbbiamo anche sistemato un problema sulla tastiera italiana, per cui su Linux Gtk l’uguale ora funziona :)
Nel frattempo il Commodore64 era duro a morire: nel 1986 la Commodore produsse una nuova versione con lo chassis bianco ma per il resto identico (il “C64C”), spia del fatto che il parco software del vecchio Commodore stava diventando un fattore cruciale per la sostenibilità del mercato.
The Commodore 64 is a fascinating machine. It is the single best selling computer model in human history. The fact that the C64 still holds that title in 2021 — close to three decades after being discontinued — is nothing short of amazing.
Because it makes me smile, let’s take a quick stroll through some of the magazine advertisements for the Commodore 64 that helped the system achieve that world record.
See Commodore 64 ads from the 1980s still make me want a C64 in 2021
K8s is a very complex beast. But it give you a very good set of security defaults, and it is also a very well done implementation of a microservice application.
After installing Docker Swarm on some Customer, we are giving up on Swarm because the Enterprise version was acquired by Mirantis and now is marketed like “K8s” engine, so Swarm seems K8s right now.
K8s business is based on the Cloud Provider services, and it is open source. Like WordPress business model, Google is always a bit forward on K8s, but you can get it up & running also on “minor cloud” provider like Digital Ocean and Linode.
I was lucky because in the last three years my Company asked to me and my group to learn K8s to reply to surging customer demand, and also to drive customer needs.
Docker Swarm seems a “underdog choice” right now, but I could be wrong.
To learn K8s my suggestion is to:
- Take some time learning K8s basics from official concept guide.
- Install Minikube and do the examples on your local machine
To be ready to the next level you should be able to:
- Deploy a simple workload
- Be able to understand how to create replica sets
- Explore some “simple” scenario like CronJobs which is a useful feature: they are simpler to understand in respect of a long running web application (i.e. you must not expose a cron job on a http port!)
- Apply a bit to be able to develop a docker application, publish to a registry and deploy on minikube. Minikube supports a toy registry you can use on Linux too, and it is quite simple to set up
After this level you can see some k8s advantages like ability to self-recover from a pod crash and so on
The next level is to
- Study Go template language, and extra “sprig” http://masterminds.github.io/sprig/ library.
- Study Helm package manager https://helm.sh/docs/topics/charts/#templates-and-values
- Have a look at the source of bitnami nginx helm chart (reason below)
- Look at a some complex example like Grana+Loki
Helm chart is the way you will deploy k8s stuff.
Bitnami charts use some standard to define helm variables you use in you deployment. For instance service.type, service.port and so on. These conventions are important because often you will deploy “stacks” of helm charts.
To understand what we mean, download and look at bitnami Nginx chart is very flexible and can be used to deploy complex reverse-proxy configuration. A good Nginx config can often be the first thing you will need to set up you architecture.
In Part2 we will explore further how to organize your K8s setup, how to install Grafana and so on
Some nice article I found on this site, and done by Lawrence Woodman, a very smart guy in our humble opinion…