From 6478f44b0b8bfbc25e2b567bcf101f9123361e1e Mon Sep 17 00:00:00 2001
From: Tchoupinax <corentinfiloche@hotmail.fr>
Date: Fri, 10 May 2024 11:15:33 +0200
Subject: [PATCH] docs: improve documentation

---
 README.md                        |  2 +-
 docs/managed-resources.md        | 30 +++++++++++++++++++++++++++++
 docs/resources-targeting-pods.md | 33 --------------------------------
 3 files changed, 31 insertions(+), 34 deletions(-)
 create mode 100644 docs/managed-resources.md
 delete mode 100644 docs/resources-targeting-pods.md

diff --git a/README.md b/README.md
index 6030718..a596bd7 100644
--- a/README.md
+++ b/README.md
@@ -63,7 +63,7 @@ We have a deployment called `api` with labels `app=api` and `kubernetes.io/name=
 
 Additional documentations:
 
-- [Service is not the only resource that target pods](docs/resources-targeting-pods.md )
+- [Managed resources](docs/managed-resources.md)
 
 ## Zero downtime testing
 
diff --git a/docs/managed-resources.md b/docs/managed-resources.md
new file mode 100644
index 0000000..5715bb1
--- /dev/null
+++ b/docs/managed-resources.md
@@ -0,0 +1,30 @@
+# Managed resourced
+
+We identify a set of resources that are matching or are linked to the pods we are trying to migrate.
+
+- #### Keda
+  - ✅ `ScaledObject`: This resources target the deployment (`.spec.scaleTargetRef.name`) and not pods. However, we don't want Keda to perfom operations during the procedure. That's why we pause the keda scaled object during the operation. This is done with an annotation meant for that purpose by keda.sh. (see `keda.go`).
+
+- #### Kubernetes
+  - 🛑 `PodDisruptionBudget`
+
+- #### Istio
+  - 🛑 `AuthorizationPolicy`
+  - ✅ `DestinationRule`: like Kubernetes services, destination rules match pods with matching labels. We repeat the same operation we did for service for the replacement.
+  - 🛑  `VirtualService` (host match the DNS name, means it match the deployment name [docs](https://istio.io/latest/docs/reference/config/networking/virtual-service/#VirtualService))
+
+- #### Monitoring
+  - 🛑 `PrometheusRule`: (rules could match pod or deployment in the query)
+  - 🛑 `PodMonitor`: matches pods by labels (`.spec.selector.matchLabels`)
+
+
+```bash
+# Display existing resources in the cluster
+kubectl api-resources --verbs=list --namespaced -o name
+```
+
+export KUBERNETES_RESOURCE=ScaledObject
+export NAME=
+export NAMESPACE=
+
+kubectl get $KUBERNETES_RESOURCE $NAME -n $NAMESPACE -o yaml | yq '.spec.selector.matchLabels'
\ No newline at end of file
diff --git a/docs/resources-targeting-pods.md b/docs/resources-targeting-pods.md
deleted file mode 100644
index c05b0c9..0000000
--- a/docs/resources-targeting-pods.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# Service is not the only resource that target pods
-
-We did the base migration considering pods are matched by service. But for a complexe app, there is a lot of resources that can match pods.
-
-## Identify resources
-
-- Kubernetes
-  - PodDisruptionBudget
-      
-- Keda
-  - ❌ ScaledObject: — `.spec.scaleTargetRef.name` (equal to the deployment name)
-    - ➡️ It is acceptable to not manage this as the migration will be fast.
-- Istio
-  - AuthorizationPolicy
-  - RequestAuthentication
-  - DestinationRule
-  - Virtual service (host match the DNS name, means it match the deployment name [docs](https://istio.io/latest/docs/reference/config/networking/virtual-service/#VirtualService))
-- Monitoring
-  - PrometheusRule (rules could match pod or deployment in the query)
-  - PodMonitor — `.spec.selector.matchLabels`
-
-## Tips
-
-```bash
-# Display existing resources in the cluster
-kubectl api-resources --verbs=list --namespaced -o name
-```
-
-export KUBERNETES_RESOURCE=ScaledObject
-export NAME=
-export NAMESPACE=
-
-kubectl get $KUBERNETES_RESOURCE $NAME -n $NAMESPACE -o yaml | yq '.spec.selector.matchLabels'
\ No newline at end of file