diff --git a/docs/design/openstack/networking-infrastructure.md b/docs/design/openstack/networking-infrastructure.md index 2bd6d7de3bd..308a2ba12c6 100644 --- a/docs/design/openstack/networking-infrastructure.md +++ b/docs/design/openstack/networking-infrastructure.md @@ -48,7 +48,7 @@ Keepalived. While the bootstrap node is up, it will have priority running the AP The Master nodes run dhcp, HAProxy, CoreDNS, and Keepalived. Haproxy loadbalances incoming requests to the API across all running masters. It also runs a stats and healthcheck server. Keepalived manages both VIPs on the master, where each -master has an equal chance of being assigned one of the VIPs. Initially, the bootstrap node has the highest priority for hosting the API VIP, so they will point to addresses there at startup. Meanwhile, the master nodes will try to get the control plane, and the OpenShift API up. Keepalived implements periodic health checks for each VIP that are used to determine the weight assigned to each server. The server with the highest weight is assigned the VIP. Keepalived has two seperate healthchecks that attempt to reach the OpenShift API and CoreDNS on the localhost of each master node. When the API on a master node is reachable, Keepalived substantially increases it's weight for that VIP, making its priority higher than that of the bootstrap node and any node that does not yet have the that service running. This ensures that nodes that are incapable of serving DNS records or the OpenShift API do not get assigned the respective VIP. The Ingress VIP is also managed by a healthcheck that queries for an OCP Router HAProxy healthcheck, not the HAProxy we stand up in static pods for the API. This makes sure that the Ingress VIP is pointing to a server that is running the necessary OpenShift Ingress Operator resources to enable external access to the node. +master has an equal chance of being assigned one of the VIPs. Initially, the bootstrap node has the highest priority for hosting the API VIP, so they will point to addresses there at startup. Meanwhile, the master nodes will try to get the control plane, and the OpenShift API up. Keepalived implements periodic health checks for each VIP that are used to determine the weight assigned to each server. The server with the highest weight is assigned the VIP. Keepalived has two separate healthchecks that attempt to reach the OpenShift API and CoreDNS on the localhost of each master node. When the API on a master node is reachable, Keepalived substantially increases it's weight for that VIP, making its priority higher than that of the bootstrap node and any node that does not yet have the that service running. This ensures that nodes that are incapable of serving DNS records or the OpenShift API do not get assigned the respective VIP. The Ingress VIP is also managed by a healthcheck that queries for an OCP Router HAProxy healthcheck, not the HAProxy we stand up in static pods for the API. This makes sure that the Ingress VIP is pointing to a server that is running the necessary OpenShift Ingress Operator resources to enable external access to the node. The Worker Nodes run dhcp, CoreDNS, and Keepalived. On workers, Keepalived is only responsible for managing the Ingress VIP. It's algorithm is the same as the one run on the masters. diff --git a/docs/dev/libvirt/README.md b/docs/dev/libvirt/README.md index 6344048cae5..11d00ea0658 100644 --- a/docs/dev/libvirt/README.md +++ b/docs/dev/libvirt/README.md @@ -113,7 +113,7 @@ First, you need to start the libvirtd TCP socket, which is managed by systemd: sudo systemctl start libvirtd-tcp.socket ``` -To make this change persistent accross reboots you can optionally enable it: +To make this change persistent across reboots you can optionally enable it: ```sh sudo systemctl enable libvirtd-tcp.socket @@ -415,7 +415,7 @@ FATA[0019] failed to run Terraform: exit status 1 it is likely that your install configuration contains three backslashes after the protocol (e.g. `qemu+tcp:///...`), when it should only be two. -### Random domain creation errors due to libvirt race conditon +### Random domain creation errors due to libvirt race condition Depending on your libvirt version you might encounter [a race condition][bugzilla_libvirt_race] leading to an error similar to: diff --git a/docs/user/aws/limits.md b/docs/user/aws/limits.md index 542ce5d7af5..e46e638a3bb 100644 --- a/docs/user/aws/limits.md +++ b/docs/user/aws/limits.md @@ -42,7 +42,7 @@ For multiple clusters, a higher limit will likely be required (and will certainl ### Example: Using North Virginia (us-east-1) -North Virginia (us-east-1) has six availablity zones, so a higher limit is required unless you configure your cluster to use fewer zones. +North Virginia (us-east-1) has six availability zones, so a higher limit is required unless you configure your cluster to use fewer zones. To support the default, all-zone installation, please submit a limit increase for VPC Elastic IPs similar to the following in the support dashboard (to create more than one cluster, a higher limit will be necessary): ![Increase Elastic IP limit in AWS](images/support_increase_elastic_ip.png) diff --git a/docs/user/azure/install_upi.md b/docs/user/azure/install_upi.md index 9371b9721c4..f4082f57252 100644 --- a/docs/user/azure/install_upi.md +++ b/docs/user/azure/install_upi.md @@ -12,7 +12,7 @@ example. * the following binaries installed and in $PATH: * [openshift-install][openshiftinstall] * It is recommended that the OpenShift installer CLI version is the same of the cluster being deployed. The version used in this example is 4.3.0 GA. - * [az (Azure CLI)][azurecli] installed and aunthenticated + * [az (Azure CLI)][azurecli] installed and authenticated * Commands flags and structure may vary between `az` versions. The recommended version used in this example is 2.0.80. * python3 * [jq][jqjson] @@ -455,7 +455,7 @@ csr-wpvxq 19m system:serviceaccount:openshift-machine-config-operator:node- csr-xpp49 19m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Approved,Issued ``` -You should inspect each pending CSR with the `oc describe csr ` command and verify that it comes from a node you recognise. If it does, they can be approved: +You should inspect each pending CSR with the `oc describe csr ` command and verify that it comes from a node you recognize. If it does, they can be approved: ```console $ oc adm certificate approve csr-8bppf csr-dj2w4 csr-ph8s8 diff --git a/docs/user/azure/limits.md b/docs/user/azure/limits.md index eb9ec64ead8..2d8435223f5 100644 --- a/docs/user/azure/limits.md +++ b/docs/user/azure/limits.md @@ -32,7 +32,7 @@ A public IP address is also created for the bootstrap machine during installatio ## Network Security Groups Each cluster creates network security groups for every subnet within the VNet. The default install creates network -security groups for the control plane and for the compuete node subnets. The default limit of 5000 for new accounts +security groups for the control plane and for the compute node subnets. The default limit of 5000 for new accounts allows for many clusters to be created. The network security groups which exist after the default install are: 1. controlplane @@ -94,13 +94,13 @@ By default, each cluster will create 3 network load balancers. The default limit 3. external * Public IP address that load balances requests to port 6443 across control-plane nodes -Additional Kuberntes LoadBalancer Service objects will create additional [load balancers][load-balancing]. +Additional Kubernetes LoadBalancer Service objects will create additional [load balancers][load-balancing]. ## Increasing limits -To increase a limit beyond the maximum, a suppport request will need to be filed. +To increase a limit beyond the maximum, a support request will need to be filed. First, click on "help + support". It is located on the bottom left menu. diff --git a/docs/user/customization.md b/docs/user/customization.md index 08729d2629b..fec93d2c080 100644 --- a/docs/user/customization.md +++ b/docs/user/customization.md @@ -39,7 +39,7 @@ The following `install-config.yaml` properties are available: The default is 10.128.0.0/14 with a host prefix of /23. * `cidr` (required [IP network](#ip-networks)): The IP block address pool. * `hostPrefix` (required integer): The prefix size to allocate to each node from the CIDR. - For example, 24 would allocate 2^8=256 adresses to each node. If this field is not used by the plugin, it can be left unset. + For example, 24 would allocate 2^8=256 addresses to each node. If this field is not used by the plugin, it can be left unset. * `machineNetwork` (optional array of objects): The IP address pools for machines. * `cidr` (required [IP network](#ip-networks)): The IP block address pool. The default is 10.0.0.0/16 for all platforms other than libvirt. @@ -72,7 +72,7 @@ For example, 10.0.0.0/16 represents IP addresses 10.0.0.0 through 10.0.255.255. The following machine-pool properties are available: -* `architecture` (optional string): Determines the instruction set architecture of the machines in the pool. Currently, heteregeneous clusters are not supported, so all pools must specify the same architecture. +* `architecture` (optional string): Determines the instruction set architecture of the machines in the pool. Currently, heterogeneous clusters are not supported, so all pools must specify the same architecture. Valid values are `amd64` (the default). * `hyperthreading` (optional string): Determines the mode of hyperthreading that machines in the pool will utilize. Valid values are `Enabled` (the default) and `Disabled`. diff --git a/docs/user/gcp/limits.md b/docs/user/gcp/limits.md index 5066b585a80..5db51f9aceb 100644 --- a/docs/user/gcp/limits.md +++ b/docs/user/gcp/limits.md @@ -55,7 +55,7 @@ A standard OpenShift installation creates 2 forwarding rules. A standard OpenShift installation creates 3 in-use global IP addresses. ### Networks -A standard OpenShift instlalation creates 2 networks. +A standard OpenShift installation creates 2 networks. ### Routers A standard OpenShift installation creates 1 router. diff --git a/docs/user/metal/README.md b/docs/user/metal/README.md index 04984f0741d..5fe576ad6dd 100644 --- a/docs/user/metal/README.md +++ b/docs/user/metal/README.md @@ -2,7 +2,7 @@ OpenShift has support for bare metal deployments with either [User provided infrastructure (UPI)](install_upi.md), or [Installer-provided -instrastructure (IPI)](install_ipi.md). +infrastructure (IPI)](install_ipi.md). The following is a summary of key differences: diff --git a/docs/user/metal/customization_ipi.md b/docs/user/metal/customization_ipi.md index fe7abecf6b5..4a620573293 100644 --- a/docs/user/metal/customization_ipi.md +++ b/docs/user/metal/customization_ipi.md @@ -57,7 +57,7 @@ and TFTP server in the cluster to support provisioning. Much of this can be customized. -* `provisioningNetorkCIDR` (optional string): Override the default provisioning network. +* `provisioningNetworkCIDR` (optional string): Override the default provisioning network. * `bootstrapProvisioningIP` (optional string): Override the bootstrap provisioning IP. If unspecified, uses the 2nd address in the provisioning network's subnet. diff --git a/docs/user/openstack/README.md b/docs/user/openstack/README.md index 2f671fab9d3..88fc1ca899a 100644 --- a/docs/user/openstack/README.md +++ b/docs/user/openstack/README.md @@ -36,9 +36,15 @@ In addition, it covers the installation with the default CNI (OpenShiftSDN), as - [Destroying The Cluster](#destroying-the-cluster) - [Post Install Operations](#post-install-operations) - [Adding a MachineSet](#adding-a-machineset) + - [Defining a MachineSet That Uses Multiple Networks](#defining-a-machineset-that-uses-multiple-networks) - [Using a Server Group](#using-a-server-group) - [Setting Nova Availability Zones](#setting-nova-availability-zones) - [Using a Custom External Load Balancer](#using-a-custom-external-load-balancer) + - [External Facing OpenShift Services](#external-facing-openshift-services) + - [HAProxy Example Load Balancer Config](#haproxy-example-load-balancer-config) + - [DNS Lookups](#dns-lookups) + - [Verifying that the API is Reachable](#verifying-that-the-api-is-reachable) + - [Verifying that Apps Reachable](#verifying-that-apps-reachable) - [Reconfiguring cloud provider](#reconfiguring-cloud-provider) - [Modifying cloud provider options](#modifying-cloud-provider-options) - [Refreshing a CA Certificate](#refreshing-a-ca-certificate) diff --git a/docs/user/openstack/install_upi.md b/docs/user/openstack/install_upi.md index 62e0d501b86..570eb051a31 100644 --- a/docs/user/openstack/install_upi.md +++ b/docs/user/openstack/install_upi.md @@ -63,7 +63,7 @@ of this method of installation. ## Prerequisites -The file `inventory.yaml` contains the variables most likely to need customisation. +The file `inventory.yaml` contains the variables most likely to need customization. **NOTE**: some of the default pods (e.g. the `openshift-router`) require at least two nodes so that is the effective minimum. The requirements for UPI are broadly similar to the [ones for OpenStack IPI][ipi-reqs]: @@ -580,7 +580,7 @@ Possible choices include: * Swift (see Example 1 below); * Glance (see Example 2 below); * Amazon S3; -* Internal web server inside your organisation; +* Internal web server inside your organization; * A throwaway Nova server in `$INFRA_ID-nodes` hosting a static web server exposing the file. In this guide, we will assume the file is at the following URL: @@ -932,7 +932,7 @@ csr-lrtlk 15m system:serviceaccount:openshift-machine-config-operator:node- csr-wkm94 16m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Approved,Issued ``` -You should inspect each pending CSR and verify that it comes from a node you recognise: +You should inspect each pending CSR and verify that it comes from a node you recognize: ```sh $ oc describe csr csr-88jp8 diff --git a/docs/user/openstack/privileges.md b/docs/user/openstack/privileges.md index ed1a4a73abb..a634a837c5b 100644 --- a/docs/user/openstack/privileges.md +++ b/docs/user/openstack/privileges.md @@ -1,6 +1,6 @@ # Required Privileges -In order to succesfully deploy an OpenShift cluster on OpenStack, the user passed to the installer needs a particular set of permissions in a given project. Our recommendation is to create a user in the project that you intend to install your cluster onto with the role *member*. In the event that you want to customize the permissions for a more restricted install, the following use cases can accomodate them. +In order to successfully deploy an OpenShift cluster on OpenStack, the user passed to the installer needs a particular set of permissions in a given project. Our recommendation is to create a user in the project that you intend to install your cluster onto with the role *member*. In the event that you want to customize the permissions for a more restricted install, the following use cases can accommodate them. ## Bring Your Own Networks diff --git a/docs/user/ovirt/install_upi.md b/docs/user/ovirt/install_upi.md index 4b8ccf1804e..57f02d81445 100644 --- a/docs/user/ovirt/install_upi.md +++ b/docs/user/ovirt/install_upi.md @@ -160,7 +160,7 @@ the URL related to the `OpenStack` qcow2 image type, like in the example below https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/pre-release/4.6.0-0.nightly-2020-07-16-122837/rhcos-4.6.0-0.nightly-2020-07-16-122837-x86_64-openstack.x86_64.qcow2.gz ``` -The version of the image should be choosen according to the OpenShift version you're about to install (in general less than or equal to the OCP +The version of the image should be chosen according to the OpenShift version you're about to install (in general less than or equal to the OCP version). Once you have the URL set in the [inventory.yml](../../../upi/ovirt/inventory.yml) a dedicated Ansible playbook will be in charge to download the `qcow2.gz` file, uncompress it in a specified folder and use it to create oVirt/RHV templates. @@ -478,7 +478,7 @@ parameters needed to reach the oVirt/RHV engine and use its REST API. **NOTE:** Some of the parameters added during the `openshift-install` workflow, in particular the `Internal API virtual IP` and `Ingress virtual IP`, will not be used because already configured in your infrastructure DNS (see [DNS](#dns) section). -Other paramenters like `oVirt cluster`, `oVirt storage`, `oVirt network`, will be used as specified in the [inventory.yml](../../../upi/ovirt/inventory.yml) +Other parameters like `oVirt cluster`, `oVirt storage`, `oVirt network`, will be used as specified in the [inventory.yml](../../../upi/ovirt/inventory.yml) and removed from the `install-config.yaml` with the previously mentioned `virtual IPs`, using a script reported in a [section below](#set-platform-to-none). @@ -612,7 +612,7 @@ The `infraID` will be used by the UPI Ansible playbooks as prefix for the VMs cr process avoiding name clashes in case of multiple installations in the same oVirt/RHV cluster. **Note:** certificates contained into ignition config files expire after 24 hours. You must complete the cluster installation -and keep the cluster running for 24 hours in a non-degradated state to ensure that the first certificate rotation has finished. +and keep the cluster running for 24 hours in a non-degraded state to ensure that the first certificate rotation has finished. ## Create templates and VMs diff --git a/docs/user/troubleshootingbootstrap.md b/docs/user/troubleshootingbootstrap.md index 79fef855636..9a8917528d0 100644 --- a/docs/user/troubleshootingbootstrap.md +++ b/docs/user/troubleshootingbootstrap.md @@ -97,7 +97,7 @@ This directory contains all the operators or their operands running on the boots For each container the directory has two files, * `.log`, which contains the log of the container. -* `.inspect`, which containts the information about the container like the image, volume mounts, arguments etc. +* `.inspect`, which contains the information about the container like the image, volume mounts, arguments etc. #### directory: bootstrap/journals @@ -107,7 +107,7 @@ The journals directory contains the logs for *important* systemd units. These un * `crio-configure.log` and `crio.log`, these units are responsible for configuring the CRI-O on the bootstrap host and CRI-O daemon respectively. * `kubelet.log`, the kubelet service is responsible for running the kubelet on the bootstrap host. The kubelet on the bootstrap host is responsible for running the static pods for etcd, bootstrap-kube-controlplane and various other operators in bootstrap mode. * `approve-csr.log`, the approve-csr unit is responsible for allowing control-plane machines to join OpenShift cluster. This unit performs the job of in-cluster approver while the bootstrapping is in progress. -* `bootkube.log`, the bootkube service is the unit that performs the bootstrapping of OpenShift clusters using all the operators. This service is respnsible for running all the required steps to bootstrap the API and then wait for success. +* `bootkube.log`, the bootkube service is the unit that performs the bootstrapping of OpenShift clusters using all the operators. This service is responsible for running all the required steps to bootstrap the API and then wait for success. There might also be other services that are important for some platforms like OpenStack, that will have logs in this directory. @@ -118,7 +118,7 @@ The pods directory contains the information and logs from all the render command For each container the directory has two files, * `.log`, which contains the log of the container. -* `.inspect`, which containts the information about the container like the image, volume mounts, arguments etc. +* `.inspect`, which contains the information about the container like the image, volume mounts, arguments etc. ### directory: resources @@ -216,4 +216,4 @@ control-plane 3 directories, 0 files ``` -The troubleshooting would require the logs of the installer gathering the log bundle, which are easily availble in `.openshift_install.log`. +The troubleshooting would require the logs of the installer gathering the log bundle, which are easily available in `.openshift_install.log`. diff --git a/docs/user/vsphere/install_upi.md b/docs/user/vsphere/install_upi.md index dd621a37ac3..3567eb75eea 100644 --- a/docs/user/vsphere/install_upi.md +++ b/docs/user/vsphere/install_upi.md @@ -284,7 +284,7 @@ The Ignition config created by the OpenShift Installer cannot be used directly b The hostname of each control plane and worker machine must be resolvable from all nodes within the cluster. -Preferrably, the hostname and IP address will be set via DHCP. +Preferably, the hostname and IP address will be set via DHCP. If you need to manually set a hostname and/or configure a static IP address, you can pass a custom networking command-line `ip=` parameter to Afterburn for configuration. In order to do so, set the vApp property `guestinfo.afterburn.initrd.network-kargs` to the `ip` parameter using this format: `ip=:::::::`, e.g. `ip=10.0.0.2::10.0.0.2:255.255.255.0:compute-1:ens192:none:8.8.8.8` diff --git a/docs/user/vsphere/vips-dns.md b/docs/user/vsphere/vips-dns.md index 1b6c576beae..3900f3416ff 100644 --- a/docs/user/vsphere/vips-dns.md +++ b/docs/user/vsphere/vips-dns.md @@ -1,4 +1,4 @@ -# IP Adresses +# IP Addresses An installer-provisioned vSphere installation requires two static IP addresses: