Fix link to Kubernetes documentation

This was missing the full TLD.

Co-authored-by: Drew Brown <[email protected]>

Author: Jonathan S. Katz

docs/content/advanced/multi-zone-design-considerations.md

@@ -13,15 +13,15 @@ When using the PostgreSQL Operator in a Kubernetes cluster consisting of nodes t
 must be taken to ensure all pods and the associated volumes re scheduled and provisioned within the same zone.  
 
 Given that a pod is unable mount a volume that is located in another zone, any volumes that are dynamically provisioned must
-be provisioned in a topology-aware manner according to the specific scheduling requirements for the pod. 
+be provisioned in a topology-aware manner according to the specific scheduling requirements for the pod.
 
 This means that when a new PostgreSQL cluster is created, it is necessary to ensure that the volume containing the database
 files for the primary PostgreSQL database within the PostgreSQL clluster is provisioned in the same zone as the node containing the PostgreSQL primary pod that will be accesing the applicable volume.
 
 #### Dynamic Provisioning of Volumes: Default Behavior
 
-By default, the Kubernetes scheduler will ensure any pods created that claim a specific volume via a PVC are scheduled on a 
-node in the same zone as that volume.  This is part of the default Kubernetes [multi-zone support](https://kubernetes.io/docs/setup/multiple-zones/). 
+By default, the Kubernetes scheduler will ensure any pods created that claim a specific volume via a PVC are scheduled on a
+node in the same zone as that volume.  This is part of the default Kubernetes [multi-zone support](https://kubernetes.io/docs/setup/multiple-zones/).
 
 However, when using Kubernetes [dynamic provisioning](https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/),
 volumes are not provisioned in a topology-aware manner.
@@ -54,14 +54,14 @@ Unfortunately, the default setting for dynamic provisinoing of volumes in mulit-
 
 Within the PostgreSQL Operator, a **node label** is implemented as a `preferredDuringSchedulingIgnoredDuringExecution` node
 affinity rule, which is an affinity rule that Kubernetes will attempt to adhere to when scheduling any pods for the cluster,
-but _will not guarantee_. More information on node affinity rules can be found [here](https://kubernetes.i/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)). 
+but _will not guarantee_. More information on node affinity rules can be found [here](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)). 
 
 By using `Immediate` for the `volumeBindingMode` in a multi-zone cluster environment, the scheduler will ignore any requested
 _(but not mandatory)_ scheduling requirements if necessary to ensure the pod can be scheduled. The scheduler will ultimately
-schedule the pod on a node in the same zone as the volume, even if another node was requested for scheduling that pod. 
+schedule the pod on a node in the same zone as the volume, even if another node was requested for scheduling that pod.
 
 As it relates to the PostgreSQL Operator specifically, a node label specified using the `--node-label` option when creating a
-cluster using the `pgo create cluster` command in order target a specific node (or nodes) for the deployment of that cluster. 
+cluster using the `pgo create cluster` command in order target a specific node (or nodes) for the deployment of that cluster.
 
 Therefore, if the volume ends up in a zone other than the zone containing the node (or nodes) defined by the node label, the
 node label will be ignored, and the pod will be scheduled according to the zone containing the volume.  
@@ -71,7 +71,7 @@ node label will be ignored, and the pod will be scheduled according to the zone
 In order to overcome this default behavior, it is necessary to make the dynamically provisioned volumes topology aware.  
 
 This is accomplished by setting the `volumeBindingMode` for the storage class to `WaitForFirstConsumer`, which delays the
-dynamic provisioning of a volume until a pod using it is created. 
+dynamic provisioning of a volume until a pod using it is created.
 
 In other words, the PVC is no longer bound as soon as it is requested, but rather waits for a pod utilizing it to be creating
 prior to binding.  This change ensures that volume can take into account the scheduling requirements for the pod, which in the
@@ -124,13 +124,13 @@ From there those storage configurations can then be selected when creating a new
 pgo create cluster mycluster --storage-config=example-sc
 ```
 
-With this approach, the pod will once again be scheduled according to the zone in which the volume was provisioned. 
+With this approach, the pod will once again be scheduled according to the zone in which the volume was provisioned.
 
 However, the zone parameters defined on the Storage Class bring consistency to scheduling by guaranteeing that the volume, and
 therefore also the pod using that volume, are scheduled in a specific zone as defined by the user, bringing consistency
 and predictability to volume provisioning and pod scheduling in multi-zone clusters.
 
-For more information regarding the specific parameters available for the Storage Classes being utilizing in your cloud 
+For more information regarding the specific parameters available for the Storage Classes being utilizing in your cloud
 environment, please see the
 [Kubernetes documentation for Storage Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/).