Revise documentation to remove outdated references to Pilot, Galley a…

…nd Citadel (istio#15413)

* Revise documentation to remove outdated references

* add v1.5 to spelling

.spelling

@@ -1216,6 +1216,7 @@ v1.27
 v1.28
 v1.29
 v1.30
+v1.5
 v1.55
 v1.55.1
 v1.7.4

content/en/about/faq/metrics-and-logs/prometheus-application-metrics.md

@@ -11,6 +11,6 @@ See [Configuration for Prometheus](/docs/ops/integrations/prometheus/#Configurat
 
 A few notes:
 
-- If the Prometheus pod started before the Istio Citadel pod could generate the required certificates and distribute them to Prometheus, the Prometheus pod will need to
+- If the Prometheus pod started before the istiod pod could generate the required certificates and distribute them to Prometheus, the Prometheus pod will need to
 be restarted in order to collect from mutual TLS-protected targets.
 - If your application exposes Prometheus metrics on a dedicated port, that port should be added to the service and deployment specifications.

content/en/docs/ops/best-practices/traffic-management/index.md

@@ -37,7 +37,7 @@ For example, consider the following destination rule as the one and only configu
 *reviews* service, that is, there are no route rules in a corresponding `VirtualService` definition:
 
 {{< text yaml >}}
-apiVersion: networking.istio.io/v1alpha3
+apiVersion: networking.istio.io/v1
 kind: DestinationRule
 metadata:
   name: reviews
@@ -61,7 +61,7 @@ You can fix the above example in one of two ways. You can either move the
 traffic policy up a level in the `DestinationRule` to make it apply to any version:
 
 {{< text yaml >}}
-apiVersion: networking.istio.io/v1alpha3
+apiVersion: networking.istio.io/v1
 kind: DestinationRule
 metadata:
   name: reviews
@@ -81,7 +81,7 @@ Or, better yet, define a proper route rule for the service in the `VirtualServic
 For example, add a simple route rule for "reviews:v1":
 
 {{< text yaml >}}
-apiVersion: networking.istio.io/v1alpha3
+apiVersion: networking.istio.io/v1
 kind: VirtualService
 metadata:
   name: reviews
@@ -105,7 +105,7 @@ but you can override the visibility with the `exportTo` field.
 For example, only requests from workloads in the same namespace can be affected by the following virtual service:
 
 {{< text yaml >}}
-apiVersion: networking.istio.io/v1alpha3
+apiVersion: networking.istio.io/v1
 kind: VirtualService
 metadata:
   name: myservice
@@ -136,7 +136,7 @@ on the destination rule lookup path:
 For example, consider the following destination rule:
 
 {{< text yaml >}}
-apiVersion: networking.istio.io/v1alpha3
+apiVersion: networking.istio.io/v1
 kind: DestinationRule
 metadata:
   name: myservice
@@ -184,14 +184,14 @@ Istio uses this restricted destination rule lookup path for two reasons:
 In situations where it is inconvenient to define the complete set of route rules or policies for a particular
 host in a single `VirtualService` or `DestinationRule` resource, it may be preferable to incrementally specify
 the configuration for the host in multiple resources.
-Pilot will merge such destination rules
+The control plane will merge such destination rules
 and merge such virtual services if they are bound to a gateway.
 
 Consider the case of a `VirtualService` bound to an ingress gateway exposing an application host which uses
 path-based delegation to several implementation services, something like this:
 
 {{< text yaml >}}
-apiVersion: networking.istio.io/v1alpha3
+apiVersion: networking.istio.io/v1
 kind: VirtualService
 metadata:
   name: myapp
@@ -227,7 +227,7 @@ To avoid this problem, it may be preferable to break up the configuration of `my
 `VirtualService` fragments, one per backend service. For example:
 
 {{< text yaml >}}
-apiVersion: networking.istio.io/v1alpha3
+apiVersion: networking.istio.io/v1
 kind: VirtualService
 metadata:
   name: myapp-service1
@@ -244,7 +244,7 @@ spec:
     - destination:
         host: service1.default.svc.cluster.local
 ---
-apiVersion: networking.istio.io/v1alpha3
+apiVersion: networking.istio.io/v1
 kind: VirtualService
 metadata:
   name: myapp-service2
@@ -261,13 +261,13 @@ spec:
     - destination:
         host: service2.default.svc.cluster.local
 ---
-apiVersion: networking.istio.io/v1alpha3
+apiVersion: networking.istio.io/v1
 kind: VirtualService
 metadata:
   name: myapp-...
 {{< /text >}}
 
-When a second and subsequent `VirtualService` for an existing host is applied, `istio-pilot` will merge
+When a second and subsequent `VirtualService` for an existing host is applied, `istiod` will merge
 the additional route rules into the existing configuration of the host. There are, however, several
 caveats with this feature that must be considered carefully when using it.
 
@@ -299,8 +299,8 @@ that the subsets are available before they are used in the routes. Otherwise, ca
 
 Creating both the `VirtualServices` and `DestinationRules` that define the corresponding subsets using a single `kubectl`
 call (e.g., `kubectl apply -f myVirtualServiceAndDestinationRule.yaml` is not sufficient because the
-resources propagate (from the configuration server, i.e., Kubernetes API server) to the Pilot instances in an eventually consistent manner. If the
-`VirtualService` using the subsets arrives before the `DestinationRule` where the subsets are defined, the Envoy configuration generated by Pilot would refer to non-existent upstream pools. This results in HTTP 503 errors until all configuration objects are available to Pilot.
+resources propagate (from the configuration server, i.e., Kubernetes API server) to the istiod instances in an eventually consistent manner. If the
+`VirtualService` using the subsets arrives before the `DestinationRule` where the subsets are defined, the Envoy configuration generated by istiod would refer to non-existent upstream pools. This results in HTTP 503 errors until all configuration objects are available to istiod.
 
 To make sure services will have zero down-time when configuring routes with subsets, follow a "make-before-break" process as described below:
 

content/en/docs/ops/common-problems/security-issues/index.md

@@ -473,7 +473,7 @@ Make sure the displayed certificate contains valid information. In particular, t
 
 ## Mutual TLS errors
 
-If you suspect problems with mutual TLS, first ensure that [Citadel is healthy](#repairing-citadel), and
+If you suspect problems with mutual TLS, first ensure that istiod is healthy, and
 second ensure that [keys and certificates are being delivered](#keys-and-certificates-errors) to sidecars properly.
 
 If everything appears to be working so far, the next step is to verify that the right [authentication policy](/docs/tasks/security/authentication/authn-policy/)

content/en/docs/ops/configuration/traffic-management/protocol-selection/index.md

@@ -49,7 +49,7 @@ The following protocols are supported:
 | `tcp`                                 | Opaque TCP data stream                                                                                                                                                  | Opaque TCP data stream                                                                                                                                                  |
 | `tls`                                 | TLS Encrypted data                                                                                                                                                      | TLS Encrypted data                                                                                                                                                      |
 | `grpc`, `grpc-web`                                | Same as `http2`                                                                                                                                                         | Same as `http2`                                                                                                                                                         |  |
-| `mongo`, `mysql`, `redis` | Experimental application protocol support. To enable them, configure the corresponding Pilot [environment variables](/docs/reference/commands/pilot-discovery/#envvars). If not enabled, treated as opaque TCP data stream | Experimental application protocol support. To enable them, configure the corresponding Pilot [environment variables](/docs/reference/commands/pilot-discovery/#envvars). If not enabled, treated as opaque TCP data stream |
+| `mongo`, `mysql`, `redis` | Experimental application protocol support. To enable them, configure the corresponding [environment variables](/docs/reference/commands/pilot-discovery/#envvars). If not enabled, treated as opaque TCP data stream | Experimental application protocol support. To enable them, configure the corresponding [environment variables](/docs/reference/commands/pilot-discovery/#envvars). If not enabled, treated as opaque TCP data stream |
 
 Below is an example of a Service that defines a `https` port by `appProtocol` and an `http` port by name: