Format fixes and rerognization

iRaindrop · iRaindrop · commit 75ba64cd2141 · 2026-01-08T21:01:30.000-08:00
Misc edits
diff --git a/docs/snippets/no-dns.md b/docs/snippets/no-dns.md
@@ -2,42 +2,42 @@
 - install/operator/knative-with-operators.md
 - install/yaml-install/serving/install-serving-with-yaml.md
 -->
-=== "No DNS"
-
-    If you are using `curl` to access [the sample applications](/docs/getting-started/first-service/), or your own Knative app, and are unable to use the "Magic DNS (sslip.io)" or "Real DNS" methods, you can evaluate Knative without altering your DNS configuration. You might have this need if minikube locally or IPv6 clusters.
-
-    To access your application using `curl` using this method:
-
-    1. Configure Knative to use a domain reachable from outside the cluster:
-
-      ```bash
-      kubectl patch configmap/config-domain \
-            --namespace knative-serving \
-            --type merge \
-            --patch '{"data":{"example.com":""}}'
-      ```
-
-    1. After starting your application, get the URL of your application:
-
-      ```bash
-      kubectl get ksvc
-      ```
-      The output should be similar to:
-      ```bash
-      NAME            URL                                        LATESTCREATED         LATESTREADY           READY   REASON
-      helloworld-go   http://helloworld-go.default.example.com   helloworld-go-vqjlf   helloworld-go-vqjlf   True
-      ```
-
-    1. Instruct `curl` to connect to the External IP or CNAME defined by the
-       networking layer mentioned in section 3, and use the `-H "Host:"` command-line
-       option to specify the Knative application's host name.
-       For example, if the networking layer defines your External IP and port to be `http://192.168.39.228:32198` and you wish to access the `helloworld-go` application mentioned earlier, use:
-
-       ```bash
-       curl -H "Host: helloworld-go.default.example.com" http://192.168.39.228:32198
-       ```
-       In the case of the provided `helloworld-go` sample application, using the default configuration, the output is:
-       ```
-       Hello Go Sample v1!
-       ```
-       Refer to the "Real DNS" method for a permanent solution.
+If you are using `curl` to access [the sample applications](/docs/getting-started/first-service/), or your own Knative app, and are unable to use the "Magic DNS (sslip.io)" or "Real DNS" methods, you can evaluate Knative without altering your DNS configuration. You might have this need if minikube locally or IPv6 clusters.
+
+To access your application using `curl` using this method:
+
+1. Configure Knative to use a domain reachable from outside the cluster:
+
+  ```bash
+  kubectl patch configmap/config-domain \
+        --namespace knative-serving \
+        --type merge \
+        --patch '{"data":{"example.com":""}}'
+  ```
+
+1. After starting your application, get the URL of your application:
+
+  ```bash
+  kubectl get ksvc
+  ```
+
+  The output should be similar to:
+
+  ```bash
+  NAME            URL                                        LATESTCREATED         LATESTREADY           READY   REASON
+  helloworld-go   http://helloworld-go.default.example.com   helloworld-go-vqjlf   helloworld-go-vqjlf   True
+  ```
+
+1. Instruct `curl` to connect to the External IP or CNAME defined by the networking layer mentioned in section 3, and use the `-H "Host:"` command-line option to specify the Knative application's host name. For example, if the networking layer defines your External IP and port to be `http://192.168.39.228:32198` and you wish to access the `helloworld-go` application mentioned earlier, use:
+
+    ```bash
+    curl -H "Host: helloworld-go.default.example.com" http://192.168.39.228:32198
+    ```
+
+    In the case of the provided `helloworld-go` sample application, using the default configuration, the output is:
+
+    ```bash
+    Hello Go Sample v1!
+    ```
+
+    Refer to the "Real DNS" method for a permanent solution.
diff --git a/docs/versioned/serving/config-network-adapters.md b/docs/versioned/serving/config-network-adapters.md
@@ -15,19 +15,6 @@ For installation instructions, see [Install serving with YAML](../install/yaml-i
 
 Review the tabbed content in this section to determine the optimal networking layer for your cluster. If you already have one of the ingress controllers installed in your cluster, we recommend using your existing installation. For most users without a supported ingress, the Kourier ingress controller is sufficient. You can expand your capabilities with the Contour ingress, a full-feature service mesh with Istio, and the Kubernetes Gateway API.
 
-The Knative tested ingress controllers (Contour, Istio, and Kourier) have the following common configurations:
-
-- Certificate management: Configurable secrets for TLS encrypted traffic. See [Using a custom TLS certificate for DomainMapping](./services/custom-tls-certificate-domain-mapping.md).
-- Timeout policies: Controls for idle, and response stream timeouts. To review timeout settings, see [Configuring the Defaults ConfigMap](./configuration/config-defaults.md).
-- Traffic visibility: Mechanisms to expose services externally or cluster-locally. See [Traffic management](./traffic-management.md).
-- The mapping of Route objects to `networking.internal.knative.dev` objects is common to these controllers.
-
-The Knative `networking.internal.knative.dev` Ingress type is generally referred to as KIngress objects.
-
-In scenarios where there are multiple networking implementations, you can create a custom ingress class to specify different ingress class annotations for each service. For more information, see [Configuring Services custom ingress class](./services/ingress-class.md).
-
-There are also third-party Knative networking options and Knative products available but are not tested or managed by the Knative community. For more information, see [Knative offerings](../install/knative-offerings.md).
-
 === "Kourier"
 
     Knative Serving network layer architecture:
@@ -134,12 +121,7 @@ There are also third-party Knative networking options and Knative products avail
 
     The Contour ingress controller, `net-contour`, bridges Knative's KIngress resources to Contour's HTTPProxy resources. Contour is a good choice for clusters that already run non-Knative apps, are already using a Contour envoy, or don't need a full-feature service mesh.
 
-    Contour provides the following additional configuration options:
-
-    - CORS policy configuration.
-    - Direct visibility classes for external and internal traffic.
-
-    Contour also supports several cluster-wide configuration options. For more information see the [Contour Configuration Reference](https://projectcontour.io/docs/1.33/configuration/).
+    You can include the full native Contour configuration as described in the [Contour Configuration Reference](https://projectcontour.io/docs/1.33/configuration/). Capabilities include CORS policy configuration, direct visibility classes for external and internal traffic, and several cluster-wide configuration options.
 
 === "Istio"
 
@@ -237,6 +219,15 @@ There are also third-party Knative networking options and Knative products avail
 
 ## Ingress configurations
 
+The Knative tested ingress controllers (Contour, Istio, and Kourier) have the following common configurations:
+
+- Certificate management: Configurable secrets for TLS encrypted traffic. See [Using a custom TLS certificate for DomainMapping](./services/custom-tls-certificate-domain-mapping.md).
+- Timeout policies: Controls for idle, and response stream timeouts. To review timeout settings, see [Configuring the Defaults ConfigMap](./configuration/config-defaults.md).
+- Traffic visibility: Mechanisms to expose services externally or cluster-locally. See [Traffic management](./traffic-management.md).
+- The mapping of Route objects to `networking.internal.knative.dev` objects is common to these controllers.
+
+The Knative `networking.internal.knative.dev` Ingress type is generally referred to as KIngress objects.
+
 Use the following command to determine which ingress controllers are installed and their status.
 
 ``` bash
@@ -280,6 +271,10 @@ kubectl patch configmap config-network -n knative-serving \
 
 If you want to install a new controller, see [Install serving with YAML](../install/yaml-install/serving/install-serving-with-yaml.md). Be aware that changing the Ingress class of an existing Route may result in undefined behavior.
 
+In scenarios where there are multiple networking implementations, you can create a custom ingress class to specify different ingress class annotations for each service. For more information, see [Configuring Services custom ingress class](./services/ingress-class.md).
+
+There are also third-party Knative networking options and Knative products available but are not tested or managed by the Knative community. For more information, see [Knative offerings](../install/knative-offerings.md).
+
 ## Gateway configurations
 
 Knative assumes two gateways in the cluster:
