Add migration guide for 1.11.1 patch (#7925)

* Add migration guide for 1.11.1 patch

* update

* update

* add a note

* change doc name in milv

docs/migration-guides/1.10-1.11.md → docs/migration-guides/1.10-1.11.1.md

@@ -1,42 +1,9 @@
-# Migrate from v1.10 to v1.11
+# Migrate from v1.10 to v1.11.1
 
-## Kyma upgrade
+>**NOTE:** Follow this guide if you want to upgrade from v1.10 to v1.11. The instructions are not mandatory if you plan to upgrade from v1.11 to v1.11.1.
 
-In this release, we introduced changes to the upgrade procedure. 
+## Installation
 
->**NOTE:** Following this upgrade guide is enough to start working with Kyma in version 1.11. **Do not** perform the upgrade steps listed on the [Kyma website](https://kyma-project.io/docs/root/kyma/#installation-upgrade-kyma-upgrade-kyma-to-a-newer-version) document.
-
-To upgrade Kyma to version 1.11, follow these steps:
-
-1. Delete the existing `kyma-installer` deployment.
-
-```bash
-kubectl delete deployment kyma-installer -n kyma-installer
-```
-2. Once the deployment is deleted, upgrade Tiller:
-
-```bash
-kubectl apply -f https://raw.githubusercontent.com/kyma-project/kyma/{NEW_KYMA_VERSION}/installation/resources/tiller.yaml
-```
-3. Verify that Tiller is running:
-
-```bash
-kubectl get po -n kube-system -l name=tiller -w
-```
-
-4. Apply the release file to the cluster to trigger the upgrade:
-```bash
-kubectl apply -f {KYMA-INSTALLER-CLUSTER-FILE}
-```
-
-5. To watch the upgrade process, run:
-
-```bash
-while true; do \
-kubectl -n default get installation/kyma-installation -o jsonpath="{'Status: '}{.status.state}{', description: '}{.status.description}"; echo; \
-sleep 5; \
-done
-```
 ### IP address assignment for the load balancer
 
 Following a successful Kyma upgrade, it may happen that the load balancer for the `apiserver-proxy` or `istio-ingressgateway` component receives a new external IP address. In such a case, you must add an entry in the DNS server to assign this IP address to a domain. 
@@ -52,7 +19,7 @@ kubectl get svc -n kyma-system apiserver-proxy-ssl  -o jsonpath="{.status.loadBa
 ```
 2.  Verify if the IP address listed in the output matches the existing DNS configuration. If not, update the DNS configuration using the instructions in [this](https://kyma-project.io/docs/#installation-install-kyma-with-your-own-domain-configure-dns-for-the-cluster-load-balancer) document.
 
-## Certificates for cluster provisioning handled by Gardener
+### Certificates for cluster provisioning handled by Gardener
 
 We have unified the way Gardener handles certificates required for cluster provisioning. Before 1.11, `apiserver-proxy` still had certificates issued under the xip.io domain with a self-signed certificate, whereas Gardener already managed other certificates. To simplify certificate management, we unified this approach to allow Gardener to manage all certificates. We have also modified TLS certificate handling to ensure Kyma components react to the TLS rotation Gardener provides. 
 Bear in mind that the domain for which you request the certificate is subject to character restrictions. This means that if the domain name in the cluster override exceeds 54 characters, installation will fail with following error:
@@ -200,4 +167,4 @@ To confirm that, check the status of Triggers:
 
 ```bash
 kubectl get triggers.eventing.knative.dev -n {NAMESPACE} {TRIGGER_NAME}
-```
+```

milv.config.yaml

@@ -86,7 +86,7 @@ files:
   - path: "./kyma/docs/compass/08-07-establish-secure-connection-with-compass.md"
     config:
       white-list-external: ["https://compass.{CLUSTER_DOMAIN"]
-  - path: "./kyma/docs/migration-guides/1.10-1.11.md"
+  - path: "./kyma/docs/migration-guides/1.10-1.11.1.md"
     config:
       white-list-external: ["https://gateway.domain/APP_NAME/v1/events",
       "https://gateway.domain/APP_NAME/events"]