first walk

[Jean-Baptiste-Lasselle]

try using kudo to develop a siimple kubernetes operator, for a simple app :

• this app has to be stateful
• web app, rest api, mongo database , and minio for file storage
• multi user, login with github, login with okta
• features for each user :
  • feature set 1 : being able to take pics with phone, pics are optimized with tools like image magick, goal is to manage my "justificatifs de notes de frais"
  • feature set 2 : doing my accounting, i can take pics as well, of credit card tickets, n bills, i can just type in new spendings, i can enter/update the amount on my account(s) anytime i check at bank , i can add scheduled income and scheduled payments. from all that i get a dashboard to monitor. Other future features: simulation of budget
• My operator in the end must be able to run those standard operations :
  • install the whole software
  • backup
  • restore
  • upgrade/downgrade
  • restart the whole stack on different global configuration
  • all those operations must use a progressive deployment pattern, where rolling back the operation is always possible, and is also making decisions based on monitoring data , like flagger (as much as possible, i would like to see what first idea i can have if i decide to implement a progressive deployment logic into my operator implemented wiht KUDO)
  • after doing all this, i want to compare my operator, with another operator, https://github.com/fluxcd/flagger :
  • first, i am going to make 3 tutorials with Flagger, to learn well how to use i, espcially to use a progressive deployment, with automatic rollback capabilities
  • then, i am going to try and do something as close as possible from what flagger does, with my operator implemented using KUDO Anyway, start with the kudo here : https://kudo.dev/docs/developing-operators/getting-started.html#prerequisites

[Jean-Baptiste-Lasselle]

I want to try all deployment strategies Flagger supports :

Everything Full Stack Published in Everything Full Stack

Guy Saar Guy Saar Follow Dec 28, 2021

· 6 min read ·

Listen

Progressive Delivery: How To Implement Flagger with Istio

What will be discussed: Progressive Delivery What is the added value of Flagger Flagger’s Deployment Strategies Canary Release Demo: how to implement Flagger with Istio Versions: Istio: v1.12.* Flagger: v1.16.0 Progressive Delivery Progressive delivery is a modern software development for gradually rolling out new features in order to limit the potential negative impact for new product features.

Flagger helps us to manage traffic routing between our current release and our new release. Flagger uses a service mesh (App Mesh, Istio, Linkerd, Open Service Mesh) or an ingress controller (Contour, Gloo, NGINX, Skipper, Traefik) for traffic routing.

To sum up:

Flagger is a progressive delivery tool that automates the release process for applications running on Kubernetes. It reduces the risk of introducing a new software version in production by gradually shifting traffic to the new version while measuring metrics and running conformance tests. https://docs.flagger.app/

What is the added value of Flagger Flagger will monitor the traffic routing for the canary release, and “decided” whether to route more traffic to the canary release or not. Not just that, we have very good control over how much traffic to route each step. For example, we can configure Flagger to query all the “response code” that is routed to the canary release service, and route 5% of the traffic every 30 minutes to the new release. Flagger will test the traffic each step, as long as the test passed it will keep routing more traffic as configured in the Canary Release.

Example: If more than 1% of the “response code” that has been routed to the canary release was from the 5XX family, we can set Flagger to halt the advance of the traffic to the new release. Otherwise Flagger will keep routing more traffic to the canary release, as configured in the canary.

Flagger can query Prometheus, Datadog, New Relic, CloudWatch, or Graphite and sends alerts via: Slack, MS Teams, Discord, and Rocket.

Flagger’s Deployment Strategies: Canary Release (progressive traffic shifting): Istio, Linkerd, App Mesh, NGINX, Skipper, Contour, Gloo Edge, Traefik, Open Service Mesh A/B Testing (HTTP headers and cookies traffic routing): Istio, App Mesh, NGINX, Contour, Gloo Edge Blue/Green (traffic switching): Kubernetes CNI, Istio, Linkerd, App Mesh, NGINX, Contour, Gloo Edge, Open Service Mesh Blue/Green Mirroring (traffic shadowing): Istio

[Jean-Baptiste-Lasselle]

here is exactly what i want to test, :

• https://docs.flagger.app/tutorials/prometheus-operator
• so i will do exactly the same, except i will write my on app in nodejs tyescript, will be a very simple rest api, and web app, it will have a prometheus endpoint to be scraped by prometheus
• I will also add a grafana dashbord so i see exactly what happens during the operations, and i can see flagger rolling back my deployment
• the result i want :

  Based on the above specification, Flagger creates the primary and canary Kubernetes ClusterIP service. During the canary analysis, Prometheus will scrape the canary service and Flagger will use the HTTP error rate and latency queries to determine if the release should be promoted or rolled back.

Another thing, there is a KUDO vs IaC : they say exactly how they advise drawing the limit between the KUDO and terraform

this means that KUDO manages state of kubernetes resources: let terraform hande all the rest, and KUDO manages the state of the statefull app.

question, if i compare already : where does my operator keeps rack of thestate of the infrastruture ? it should have a database where it persists the current desired state

[Jean-Baptiste-Lasselle]

https://medium.com/everything-full-stack/progressive-delivery-how-to-implement-flagger-with-istio-cb81aab800b8