diff --git a/modules/installation-approve-csrs.adoc b/modules/installation-approve-csrs.adoc index 2b418490350..1bbf4c4a461 100644 --- a/modules/installation-approve-csrs.adoc +++ b/modules/installation-approve-csrs.adoc @@ -47,7 +47,7 @@ endif::[] = Approving the certificate signing requests for your machines [role="_abstract"] -To allow newly added machines to join your {product-title} cluster, you can confirm that pending certificate signing requests (CSRs) are approved or approve them yourself. Approve client requests first, then server requests. +To allow newly added machines to join your {product-title} cluster, confirm that the cluster approves pending certificate signing requests (CSRs), or approve them yourself. Approve client requests first, then server requests. .Prerequisites @@ -116,12 +116,12 @@ endif::ibm-z,ibm-z-kvm[] + [NOTE] ==== -You must approve your CSRs within an hour of adding the machines to the cluster. If you do not approve them within an hour, the certificates rotate, and more than two certificates are present for each node. You must approve all of these certificates. After the client CSR is approved, the kubelet creates a secondary CSR for the serving certificate, which requires manual approval. The subsequent serving certificate renewal requests are then automatically approved by the `machine-approver` if the Kubelet requests a new certificate with identical parameters. +You must approve your CSRs within an hour of adding the machines to the cluster. If you do not approve them within an hour, the certificates rotate, and more than two certificates are present for each node. You must approve all of these certificates. After you approve the client CSR, the kubelet creates a secondary CSR for the serving certificate, which requires manual approval. The `machine-approver` then automatically approves later serving certificate renewal requests if the kubelet requests a new certificate with the same parameters. ==== + [NOTE] ==== -For clusters running on platforms that are not machine API enabled, such as bare metal and other user-provisioned infrastructure, you must implement a method of automatically approving the kubelet serving certificate requests (CSRs). If a request is not approved, then the `oc exec`, `oc rsh`, and `oc logs` commands cannot succeed, because a serving certificate is required when the API server connects to the kubelet. Any operation that contacts the Kubelet endpoint requires this certificate approval to be in place. The method must watch for new CSRs, confirm that the CSR was submitted by the `node-bootstrapper` service account in the `system:node` or `system:admin` groups, and confirm the identity of the node. +For clusters running on platforms that are not machine API enabled, such as bare metal and other user-provisioned infrastructure, you must implement a method of automatically approving the kubelet serving certificate requests (CSRs). If you do not approve a request, the `oc exec`, `oc rsh`, and `oc logs` commands cannot succeed, because a serving certificate is required when the API server connects to the kubelet. Any operation that contacts the kubelet endpoint requires this certificate approval to be in place. The method must watch for new CSRs, confirm that the `node-bootstrapper` service account in the `system:node` or `system:admin` groups submitted the CSR, and confirm the identity of the node. ==== + ** To approve them individually, run the following command for each valid CSR: @@ -147,7 +147,7 @@ $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name} Some Operators might not become available until some CSRs are approved. Each node submits two CSRs, so you might need to run the command to approve CSRs multiple times. ==== -. Now that your client requests are approved, you must review the server requests for each machine that you added to the cluster: +. After you approve your client requests, review the server requests for each machine that you added to the cluster: + [source,terminal] ---- @@ -183,7 +183,7 @@ where: $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve ---- -. After all client and server CSRs have been approved, the machines have the `Ready` status. Verify this by running the following command: +. After you approve all client and server CSRs, the machines have the `Ready` status. Verify this by running the following command: + ifndef::ibm-power[] [source,terminal] diff --git a/modules/installation-aws-creating-cloudformation-stack-compute.adoc b/modules/installation-aws-creating-cloudformation-stack-compute.adoc index 53f677682cf..227e1ef1ccf 100644 --- a/modules/installation-aws-creating-cloudformation-stack-compute.adoc +++ b/modules/installation-aws-creating-cloudformation-stack-compute.adoc @@ -5,18 +5,18 @@ :_mod-docs-content-type: PROCEDURE [id="installation-aws-creating-cloudformation-stack_{context}"] -= Creating the CloudFormation stack for compute machines += Creating the `CloudFormation` stack for compute machines [role="_abstract"] -You can create a stack of {aws-short} resources for the compute machines by using the CloudFormation template that was previously shared. +You can create a stack of {aws-first} resources for the compute machines by using the provided `CloudFormation` template. [IMPORTANT] ==== -When you use the CloudFormation template for the control plane machines, the template provisions all three control plane machines with a single stack; however, when you use the CloudFormation template to deploy the compute machines, you must create the number of stacks based on the number that you defined in the `install-config.yaml` file. Each stack is provisioned once for each machine. To provision a new compute machine, you must change the stack name. +When you use the `CloudFormation` template for the control plane machines, the template provisions all three control plane machines with a single stack; however, when you use the `CloudFormation` template to deploy the compute machines, you must create the number of stacks based on the number that you defined in the `install-config.yaml` file. You provision each stack once for each machine. To provision a new compute machine, you must change the stack name. ==== .Procedure -* To create the CloudFormation stack for compute machines, run the following command: +* To create the `CloudFormation` stack for compute machines, run the following command: + [source,terminal] ---- @@ -27,9 +27,9 @@ $ aws cloudformation create-stack --stack-name \ + where: -``:: Specifies the `` with the name for the CloudFormation stack, such as `cluster-worker-1`. You need the name of this stack if you remove the cluster. -`