WIP: just writing

kube/values-main.yaml

@@ -14,7 +14,7 @@ values: |
     settings:
       secret: $ARGO_REMARK_SECRET
       admin:
-        sharedEmail: allanger@zohomail.com
+        sharedEmail: allanger@badhouseplants.net
       oauth:
         github:
           enabled: true

src/assets/jsconfig.json

@@ -3,7 +3,7 @@
   "baseUrl": ".",
   "paths": {
    "*": [
-    "../themes/Stack/assets/*"
+    "../themes/stack/assets/*"
    ]
   }
  }

src/content/post/allanger/do-we-need-continuous-reconciliation.md

@@ -8,6 +8,44 @@ categories = [
 ]
 +++
 
-> Well, alright, it depends
+> Well, alright, I guess it depends
 
-First, let's figure out what we are deploying and how. Let's imaging that we're 
+## Intro
+
+First, let's figure out what **continuous reconciliation** stands for. Considering this post's categories, I guess we're talking **Kubernetes** here. And **continuous reconciliation** that resources deployed to kubernetes are not only synced once, when you run `kubectl apply`, but all the time. Basically, every 30s (or whatever reconciliation period you got) something is running `kubectl apply`.
+
+The idea behind that (as I see) is that you're always aware of what's deployed to you cluster, by looking at the code. Let's say, there is a git rЖepo `k8s-deployments`, and it has all the resources that you want to have running in your cluster.
+
+> It made a lot of sense to when I heard for the first time, not I'm rather sceptical about it.
+
+As far as I understand, having all you resource continuously reconciled is **GitOps**, not only that of course, it's just a part of it. At least that's what I've been told by some engineers.
+
+## GitOps
+
+I don't think that I'm the one to be talking about **GitOps** because everytime I was trying to bring my point on that, I've been told that I don't know what **GitOps** is.
+
+> To be honest, after many conversations with different people, I think that GitOps is just a buzzword for selling technologies and service, correct me if I wrong.
+
+I can't talk about others opinion, so I'll jsut try to express mine. I think that **GitOps** is when you have a desired state of your infrastucture written in code, and a mechanism to make your real infrastucture state correspond the desired one.
+
+Let's not lean towards Kubernetes and let's imaging that you, as a SRE team, have to manage Kubernetes clusters. In your cluster you'll have to run an application that is being developed by the company you're working for, and some dependencies, that this application needs in order to run.
+
+> Also, I guess it is an opinion that many of SREs won't share. I guess that the SRE team shouldn't be integrated to development teams. In my opinioin, SRE teams should provide ingfa-as-a-service to developes and help them use it.
+
+So, after all, you cluster will contain approximately this:
+- Very base layer
+    - CNI plugin (E.G. Cilium)
+    - CoreDNS
+    - Longhorn (Maybe you're self-hosting and you need a storage)
+    - MetalLB (Again, maybe you're self-hosting)
+- System layer
+    - Cert Manager
+    - Istio (As an Ingress, because that's what I'm using)
+- Monitoring layer
+    - Kube Prometheus Stack
+    - Loki
+    - Promtail
+- Application specific dependencies
+    - Zalando Postgres Operator
+    - Redis Operator
+- Application layer