Af Emil Thorenfeldt fra Magenta
KubeCon/CloudNativeCon 2021 er en konference, der afholdes årligt af Linux Foundation-projektet Cloud Native Computing Foundation. Aktiviteterne er kombineret med Gitlab Commit + Cloud Native Rust Day og dette års konference var den første virtuelle udgave. Læs med her for et indblik i alt, der rører på sig indenfor Kubernetes, Docker, Gitlab CI og Cloud native software.
Help advance container technology and align the tech industry around its evolution
The Cloud Native Computing Foundation (CNCF)
Dag 1: Mandag – Cloud Native Rust Day
Opening remarks
Rust er nu det næstmest anvendte sprog (efter Go) i CNCF ifølge CNCFs CTO.
The Rusty Boat
Super intro til at arbejde med Kubernetes i Rust, og hvorfor Go (ironisk nok) er et dårligt fit. Mest rettet mod Rust-begyndere.
Why the future of the cloud will be built on Rust
Gennemgang af cloud-historik, f.eks. overgang fra pets til cattle, scripting-sprogs indtog i config management (Chef, Puppeter, Ansible) efterfulgt af introduktion af Zookeeper, Mesos, Aurura, Finagle, Linkerd.
Næste skridt: cloud native v1 bestående af Docker, Kubernetes, gRPC, Envoy, Linkerd v2. Fjerner endegyldigt afhængighed af hosts.
Linkerd v2s proxy er skrevet i Rust frem for Go fordi det tilbyder bedre sikkerhed, performance og maintainability. Flytter fejl fra runtime til compile time.
Lige som med foregående talk meget kærlighed til tonic til gRPC, kube-rs til Kubernetes og tokio som async runtime. Generel tro på at Go er på vej (lidt) ud i cloud-sammenhæng til fordel for Rust.
The Rust Borrow Checker – A Deep Dive
En gennemgang af hvordan Rusts compiler er bygget op og hvordan Rusts borrow checker kan være en striks men velmenende ven i udviklingsprocessen.
Building Cloud-native applications with Rust
Fremragende gennemgang af hvorfor og hvordan man bør skrive cloud-native applikationer i Rust og hvilke problemer man kan løbe ind i.
Allocating Less: Really Thin Rust Cloud Apps
Tips til hvordan man 1) optimerer sine (Rust-)applikationer og 2) benchmarker allokeringer.
Leveraging State Machines to Build Operators in Rust
Om krator, en Kubernetes operator-implementation i Rust. Rusts typesystem gør det muligt at verificere korrekthed (transitioner mellem gyldige states) ved compile time. Svært gennemtrængelig talk, hvis man ikke er bekendt med operators men god intro til implementation af state machines i Rust.
Panel Discussion: Rust in the Cloud
Der bliver snakket om erfaringer med at bruge Rust i cloud-native applikationer, bl.a.:
- Rust i produktion er kedeligt – færre runtime-issues
- Ekspressivt typesystem gør det muligt at repræsentere data og adfærd koncist
- Fravær af garbage collection gør performance stærk og pålidelig
- Økosystemet er stadig ungt, og der mangler stadig high-level tooling (f.eks. til debugging) som dog er in progress
- Alt der har med networking at gøre er sikkerhedskritisk og historien viser at det er svært/dyrt at gøre det i C uden at skyde sig selv i foden
- Især egnet til infrastruktur hvor sikkerhed, korrekthed og performance er tvingende nødvendigt
- Rust er det ultimative shift left-sprog
- Bedste integration til WebAssembly, som har meget potentiale i cloud-native-verdenen
- Oprettelsen af Rust Foundation med Microsoft, AWS, Google, Facebook, m.fl. som backers giver håb om at Rust om et par år har et lige så modent økosystem som Go
Cloud Native Rust Workshop
En code-along hvor man skrev en multi-threaded TCP-server. Den færdige kode ser ca. sådan her ud: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0a50e08ed776b1a01de0838fd925e210.
Dag 2: Tirsdag – Gitlab Commit at KubeCon: DevOps
Welcome keynote
Det forventelige PR-spiel omkring Gitlabs vækst og open source-værdier. Gitlab Commit afholdes 1-2 gange om året og dette er den første, der er integreret i KubeCon. Årets tema er “Innovate together” og fokus er på hvordan DevSecOps og cloud native hænger sammen.
Adopting cloud native at the SKAO
Om hvordan en gigantisk global rumforskningsinstitution har taget DevSecOps og SAFe Agile i brug. Det tog dem 3 måneder at tage Gitlab i brug til den komplette SDLC, dvs. byg, test, monitorering, release, deployment, etc., altsammen håndteret vha. Gitlabs indbyggede integrationer til Kubernetes, ElasticSearch, Prometheus, Nexus, mv.
Den grundlæggende idé er at alle udviklere kan arbejde på samme måde og at hosting, storage mv. er abstraheret væk. Deres setup understøtter AWS EKS, GKE, bare-metal deployments. Vigtigste takeaway var hvordan Gitlab kan fungere som limen der holder de forskellige dele sammen.
Cloud Native Deployments: From Jenkins to Gitlab CI
Om udfordringerne med Jenkins’ arkitektur, performance og kompleksitet og hvordan man kan ende med en Jenkins-silo af devops-udviklere, som er de eneste der er i stand til at debugge problemer.
Skift til Gitlab CI medførte ejerskab hos de enkelte teams. Udbredt brug af includes, så teams blot skal skrive én linje for at få f.eks. linting, og så man kan opdatere konfiguration fra et centralt repo. Dog stadig udfordringer med distribueret YAML til konfiguration af Kubernetes.
Næste iteration: flytte Kubernetes-YAML ind i centralt repo og erstatte hjemmerullet jinja-templating med Helm. Integration i .gitlab-ci.yml vha. førnævnte includes + brug af ArgoCDs Rollouts-funktionalitet til canary deployments.
10/10 talk would recommend.
Amazon EKS, VMWare TKGI & Google GKE all within ONE Gitlab
Om hvordan man uden problemer kan bruge adskillige forskellige Kubernetes providers i én pipeline vha. Gitlab AutoDevOps. Ret vildt hvordan næsten alt er konfigureret og styret via Gitlabs UI inkl. canary rollouts, løbende udrulning, review environments, skalering ud fra metrkiker og meget mere.
GitOps in a regulated environment using Gitlab and Keptn
Om migreringen fra et udvalg af versionsstyringssystemer og platforme til Gitlab CI/CD + Kubernetes.
Første iteration: build + test + package + deploy til test efterfulgt af PR til separat repo hvor man bad om at få deployet i staging/prod., ping til QA-afdelingen for at de kunne køre load tests mv.
Anden iteration: monolitiske pipelines bygget op omkring en 1000 linjer lang .gitlab-ci.yml. Stærkt konsolideret men svært at vedligholde
Tredje iteration: Gitlab Ultimate + Keptn til at triggere events efter deployments, f.eks. JMeter-loadtesting efter deploy på dev og automatisk opgradering fra dev til prod, hvis tests går godt. Gitlab snakker med Keptn som pinger Gitlab, når ting går godt/skidt
Næste iteration: Gitlab CI står blot for at bygge og køre overfladiske tests, resten overladt til Keptn
Fordele ved Keptn: modulært, deklarativt, event-driven. Virker umiddelbart enormt spændende!
How Gitlab can save your Kubernetes environment from being hijacked
Step-by-step-gennemgang af hvordan man hijacker et Kubernetes cluster, dernæst en gennemgang af Gitlab-features, som kan mitigere angreb, herunder obligatoriske approvals, SAST, DAST, fuzzing, dependency scanning og secret detection. Desværre er de fleste ultimate features.
Derudover en række best practices i stil med Labs’ audit plan:
- Rootless containers
- Readonly containers
- Disabling af egress
- Distroless containers
- etc.
Fin og oplysende talk, men meget møntet på Kubernetes-workloads og ikke så Gitlab-fokuseret som håbet.
Secure GitOps with the Gitlab Kubernetes Agent
Om progression fra Ops til SRE til DevOps til GitOps. GitOps består af:
- Single source of truth for Ops
- Automated deployments
- Automated promotions between environments
- Self-healing services
- Declarative Ops
- Single & integrated interface for Dev + Ops
Værktøjerne til ovenstående er kun delvist modne, men Gitlab er det pt. bedste bud (ifølge speakeren) til at lave et integreret interface.
Glimrende talk hele vejen rundt med udgangspunkt i https://gitlab.com/gitlab-examples/ops/configure-product-walkthrough/
Dag 3: Onsdag – KubeCon + CloudNativeCon
Keynote sessions
Mange korte sessions, som det ikke giver mening at skrive noter om. Dog masser af highlights, bl.a. gennemgangen af CNCFs sandbox + intro til Flux v2 / GitOps Toolkit, som virker utroligt spændende.
TechDocs: Unlocking the Potential of Engineers’ Collective Knowledge
Om Spotifys portal ved navn Backstage til projekttemplates, komponentkatalog og – vigtigst – teknisk dokumentation. Backstage er vokset ud af Spotify og incubates nu i CNCF.
Det er let at blive besnæret af flashy præsentationer, men jeg synes virkelig at Backstage ser utroligt fedt ud. Efter talken har jeg snakket lidt med oplægsholderen omkr. integration af andre static site generators (dvs. mdbook), hvilket ikke er muligt pt. men måske bliver det i fremtiden.
We Didn’t Start the Fire: Communication Breakdowns and How to Prevent Them
Om hvordan deprecation af docker-shim fra Kubernetes gjorde at en masse mennesker troede at deres clusters ville sprænge i luften på trods af velmenende forsøg på at kommunikere. Problermerne skyldtes overvurdering af hvor meget slutbrugerne vidste om de underliggende teknologier. Essentielt en offentlig post-mortem – mega interessant.
CERN’s 1500 Drupal Websites on Kubernetes: Sailing With Operators
Hvordan et par juniorudviklere satte 1500 Drupal-sites op vha. OpenShift og Kubernetes operators, herunder automatiske rollbacks mv.
Writing for Developers: Take your Project Docs to the Next Level
Afholdt af CNCF selv. Tips til hvordan man skriver god dokumentation til open source-projekter. Meget er overførbart på Udviklerhåndbogen/Labs-håndbogen og anden intern dokumentation samt selvfølgelig offentlig dokumentation af OS2MO, OS2DS, mv.
Eksempler på god dokumentation: https://vitess.io/docs/ og https://prometheus.io/docs/prometheus/latest/querying/basics/
- Find ud af hvad brugerens mål er
- Snak med brugerne
- Hold styr på hvilke spørgsmål der dukker op oftest
- Tænk dokumentation ind før implementationsarbejdet – ellers kommer man til at skrive dokumentation ud fra et perspektiv som en udvikler der kender det pågældende produkt indgående
- Værdsæt begynder-mindset blandt brugerne! Dumme spørgsmål er de mest velkomne
- Tænk high-level – hvorfor bør læseren være interesseret i det de læser om?
- Tænk i Concepts (high-level overblik), tasks (hvordan installerer man, hvordan bruger man, etc.) og references (uddybende information, f.eks. API-spec og anden (oftest auto-genereret) udførdlig dokumentation)
- Tænk i flow – hvad forventer man at folk læser først? Og derefter?
- Learn more-links er stadig et hit!
Dag 4: Torsdag – KubeCon + CloudNativeCon
Keynote sessions
Lidt om Kubernetes-projektets udvikling, ny release cadence (3 releases om året), fokus på bedre async-kommunikation, meget i forlængelse af “We Didn’t Start the Fire”-talken onsdag. Derudover en fin intro til Linkerd (en k8s service mesh-implementation), dets community og hvordan Linkerd var en central del af en række COVID-19-tiltag.
Virkelig god intro til Knative, et VMWare-tiltag for at nedsætte kompleksiteten forbundet med k8s. Kompleksitet + kulturændringer toppede CNCFs 2020 survey i listen over største udfordringer forbundet med at blive cloud-native. Knative er et forsøg på at undgå at man skal være “YAML Engineer” og gøre k8s-deployments event-driven.
Deutche Telekom snakker om hvordan de byggede en intern k8s-platform ved navn DAS SCHIFF (emphasis mine) og de unikke udfordringer for en TelCo-virksomhed, især 5G. Bygget op omkring ClusterAPI og FluxCD og inspireret af Weaveworks’ GitOps-initiativer.
Jaeger Intro and Deep Dive
Throwback til Emil Ms præsentation af tracing under vores udviklerdage for et år siden. “Finding what is broken is often more difficult than why” <- jep. Generelt god gennemgang, især af deployment-topologier, men (selvfølgelig) meget møntet på k8s-workloads.
GitOps Working Group Update
Endnu et bud på hvad GitOps egentlig er:
- Runtime environment-agnostisk (dvs. ikke bundet op på k8s)
- Et interface til git som er et interface til Ops
- Automatisering som følge af git-handlinger
- Kræver convergent automation
- Feedback-loop fra runtime tilbage til Git-repo
GitOps WG er lavet for at udbrede viden, værktøjer og metodikker som gør Ops og infra lettere i cloud native-applikationer samt sikre at værktøjer er interoperable. Arbejder på første udgave af “GitOps Principles” (se OpenGitOps og GitOps WG på github) og en hjemmeside. Arbejder også på Podtato head-repoet og andre eksempler.
GitOps Principles:
- State er deklarativ
- State er versioneret med immutable versioner og komplet versionshistorik (dvs. git)
- Software-agenter fungerer som reconcilers og sammenligner konstant (og automatisk) desired state og actual state
- Der findes som udgangspunkt kun denne måde at arbejde på, dvs. al Ops foregår gennem versionerede deklarationer, ingen SSH, ingen
kubectl apply, etc.
Flux, ArgoCD, ClusterAPI er eksempler på reconcilers.
GitOps kan karakteriseres som CD+CO, hvor CO = continuous operations.
Lessons Learned Deploying Traditional Web Applications on Top of Kubernetes
Traditionelle webapps kategoriseres som applikationer som ikke lever op til 12factor-principperne:
- Applikationen har state
- Kode, data og config er sammenfiltret
- Der er startup-tid
- Man kan ikke skalere horisontalt
- Dependency-håndtering er ikke reproducerbar
Herefter følger en introduktion til container images generelt samt nogle best practices + en intro til Helm charts. Dernæst sikkerhedsanbefalinger meget i tråd med Labs’ audit plan og tips til hvordan man optimerer image-størrelse. Mange gode begyndertips for udviklere, der ikke har erfaring med at skrive Dockerfiles.
Dag 5: Fredag – KubeCon + CloudNativeCon
Keynote sessions
En del snak om at WebAssembly er fremtiden for cloud native. Mesh som erstatning for monolitiske applikationer, fordi et mesh giver discoverability og observability, når man har splittet sine interne bibliotekskald ud i separate services, som ellers kan være svære at overskue. Typer af mesh: service mesh, network mesh, media stream mesh, data mesh. Fordi det er deklarativt kan man bedre holde styr på compliance. Et mesh understøtter: Discover, consume, connect, observe. Interessant snak om RISC-V. CNCF har bidraget til at fjerne vendor lock-in og cloud native giver abstraktioner over det bare metal, applikationer kører på, men vi kører stadig alt på proprietær hardware. For at holde liv i Moore’s Law er man begyndt at kigge på Domain Specific Acceleration: hardware bygget specifikt til deres formål. RISC-V er en åben ISA (modsat x86, ARM, etc.). Dette gør det muligt for firmaer at udvikle forskellige typer hardware oven på ISA-specifikationen i stil med hvordan der er et utal af produkter oven på den åbne Kubernetes-standard. Kubernetes kører allerede på RISC-V og der foregår meget upstream-arbejde med at tilføje support i diverse fundamentale biblioteker (Docker, etc.) og programmeringssprog (Go, Rust). Interessant snak om skalering af Kubernetes-communitiet til ca. 20.000 unikke commit-bidragydere om året og pandemi-udfordringerne, samt tiltag for at styrke transparens og inklusivitet. Fascinerende snak om hvordan Irland implementerede deres COVID-tracking app (COVID Green) og økosystemet rundt om det, samt hvordan man håndterede privatlivsbekymringer.
High Throughput with Low Resource Usage: A Logging Journey
Fra utrukturerede Apache-logs til konsoliderede logs, herunder indsamling, datatransformation, buffering, afsendelse med udgangspunkt i Fluent Bit. Fluent Bit er en C-implementation af dele af Fluentd. Meget fin intro til logging generelt og specifikt med Fluent(d|bit).
Petabyte Scale Logging with Fluentd and Fluent Bit
Om brug af streaming og andre teknologier til at håndtere gigantiske datamængder. Zonede en smule ud da jeg komisk nok sad og skrev fluentd-konfiguration, men så kunne jeg til gengæld bruge live Q&A-funktionaliteten til at få input til test og validering af fluent-config.
How We are Dealing with Metrics at Scale on GitLab.com
Udfordringer:
- Mange falske positiver og generelt low-quality “flappy” alerts
- Low recall: proportion of significant events detected. Mange problemer blev først opdaget da folk på twitter skrev at Gitlab var broken
- Dashboards var ofte broken fordi de var ude af sync med metrics
- Metrikker var separate fra alerting rules som var separate fra dashboards, hvilket gav siloer
Løsninger:
- Udvikle et fælles set key metrics
Med udgangspunkt i Googles 4 golden signals. Bryd applikationen ned i services og i deres respektive komponenter og lav metrikker for hver af dem. Brug dem til at lave SLI’er: satisfactory latency pr. total requests (en inverteret SLI dvs. 100% = godt) og errors pr. total requests.
- Bruge key metrics som udgangspunkt for alerts
Lav thresholds for de to SLIs = SLO. Startede med at være lige så dårligt, fordi det var basale “Opfylder vi vores SLI over 5 minutter”? Anbefaler Google SRE Handbooks “Alerting on SLOs”, som dog introducerer meget kompleksitet og kræver bedre tooling & automatisering af konfiguration. De lavede et versioneret metrics catalog hvor man konfigurerer få værdier og automatisk får genereret Prometheus-metrikker og Grafana-dashboards.
- Konsolidere information for at gøre det muligt for Ops at undersøge problemer
Første løsning var PromQL + GeneratorURL (et værktøj til at lave links til sider, der forårsager problemer). Gav ikke nok kontekst. I stedet integreret i Grafana, med Grafana som launchpad for andre observability tools (Sentry, Jaeger, Kibana, Stackdriver, mv.).
Efter alt var sat op ramte man loftet for Prometheus’ kapacitet. Første løsning var at lave en prometheus-instans for hver applikation. Let at overskue, men gjorde at man ikke kunne måle SLIs/SLOs på tværs af applikationer. Næste løsning var sharding på tværs af zonal k8s clusters, som dog heller ikke virkede perfekt. Endelig løsning: Thanos til at aggregere prometheus-metrikker.
Links til videre læsning og læring:
Anbefalinger
