Skip to content

Commit

Permalink
OSDOCS#10356: Update: Hoted control planes on AWS is GA in OCP 4.16
Browse files Browse the repository at this point in the history
  • Loading branch information
xenolinux committed May 9, 2024
1 parent 3841d15 commit b945874
Show file tree
Hide file tree
Showing 2 changed files with 62 additions and 25 deletions.
5 changes: 1 addition & 4 deletions hosted_control_planes/hcp-getting-started.adoc
Expand Up @@ -38,11 +38,8 @@ You can view the procedures by selecting from one of the following providers:
[id="hcp-getting-started-aws"]
== {aws-first}

:FeatureName: Hosted control planes on the {aws-short} platform
include::snippets/technology-preview.adoc[]

* link:https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.10/html/clusters/cluster_mce_overview#hosting-cluster-aws-infra-reqs[AWS infrastructure requirements]: Review the infrastructure requirements to create a hosted cluster on {aws-short}.
* link:https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.10/html/clusters/cluster_mce_overview#hosting-service-cluster-configure-aws[Configuring hosted control plane clusters on AWS (Technology Preview)]: The tasks to configure hosted control plane clusters on {aws-short} include creating the {aws-short} S3 OIDC secret, creating a routable public zone, enabling external DNS, enabling {aws-short} PrivateLink, and deploying a hosted cluster.
* link:https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.10/html/clusters/cluster_mce_overview#hosting-service-cluster-configure-aws[Configuring hosted control plane clusters on AWS]: The tasks to configure hosted control plane clusters on {aws-short} include creating the {aws-short} S3 OIDC secret, creating a routable public zone, enabling external DNS, enabling {aws-short} PrivateLink, and deploying a hosted cluster.
* xref:../networking/hardware_networks/configuring-sriov-operator.adoc#sriov-operator-hosted-control-planes_configuring-sriov-operator[Deploying the SR-IOV Operator for hosted control planes]: After you configure and deploy your hosting service cluster, you can create a subscription to the Single Root I/O Virtualization (SR-IOV) Operator on a hosted cluster. The SR-IOV pod runs on worker machines rather than the control plane.

[id="hcp-getting-started-ibmz"]
Expand Down
82 changes: 61 additions & 21 deletions modules/debug-nodes-hcp.adoc
Expand Up @@ -18,6 +18,16 @@ include::snippets/technology-preview.adoc[]
.Procedure

. Create the hosted control plane namespace by entering the following command:

+
[source,bash]
----
$ oc create ns <hosted_cluster_namespace>-<hosted_cluster_name>
----
+
Replace `<hosted_cluster_namespace>` with your hosted cluster namespace name, for example, `clusters`. Replace `<hosted_cluster_name>` with your hosted cluster name.

. Address any error messages in the status of the `HostedCluster` and `NodePool` resources:

.. Check the status of the `HostedCluster` resource by running the following command:
Expand All @@ -36,23 +46,32 @@ $ oc get hc -n <hosted_cluster_namespace> <hosted_cluster_name> -o jsonpath='{.s
+
If you did not find any error messages in the status of the `HostedCluster` and `NodePool` resources, proceed to the next step.

. Check if your worker machines are created by running the following commands, replacing values as necessary:
. Check if your worker machines are created by running the following command:
+
[source,terminal]
----
$ oc get machines.cluster.x-k8s.io -n <hosted_control_plane_namespace>
----

. Check if your AWS machines are created by running the following command:
+
[source,terminal]
----
$ HC_NAMESPACE="clusters"
$ HC_NAME="cluster_name"
$ CONTROL_PLANE_NAMESPACE="${HC_NAMESPACE}-${HC_NAME}"
$ oc get machines.cluster.x-k8s.io -n $CONTROL_PLANE_NAMESPACE
$ oc get awsmachines -n $CONTROL_PLANE_NAMESPACE
$ oc get awsmachines -n <hosted_control_plane_namespace>
----

. If worker machines do not exist, check if the `machinedeployment` and `machineset` resources are created by running the following commands:
. If worker machines do not exist, check if the `machinedeployment` resources are created by running the following command:
+
[source,terminal]
----
$ oc get machinedeployment -n $CONTROL_PLANE_NAMESPACE
$ oc get machineset -n $CONTROL_PLANE_NAMESPACE
$ oc get machinedeployment -n <hosted_control_plane_namespace>
----

. If worker machines do not exist, check if the `machineset` resources are created by running the following command:
+
[source,terminal]
----
$ oc get machineset -n <hosted_control_plane_namespace>
----

. If the `machinedeployment` and `machineset` resources do not exist, check logs of the HyperShift Operator by running the following command:
Expand All @@ -66,14 +85,14 @@ $ oc logs deployment/operator -n hypershift
+
[source,terminal]
----
$ oc logs deployment/capi-provider -c manager -n $CONTROL_PLANE_NAMESPACE
$ oc logs deployment/capi-provider -c manager -n <hosted_control_plane_namespace>
----

. If worker machines exist and are provisioned in the cluster, ensure that machines are initialized through Ignition successfully by checking the system console logs. Check the system console logs of every machine by using the `console-logs` utility by running the following command:
+
[source,terminal]
----
$ ./bin/hypershift console-logs aws --name $HC_NAME --aws-creds ~/.aws/credentials --output-dir /tmp/console-logs
$ ./bin/hcp console-logs aws --name <hosted_cluster_name> --aws-creds ~/.aws/credentials --output-dir /tmp/console-logs
----
+
You can access the system console logs in the `/tmp/console-logs` directory. The control plane exposes the Ignition endpoint. If you see an error related to the Ignition endpoint, then the Ignition endpoint is not accessible from the worker nodes through `https`.
Expand All @@ -84,26 +103,47 @@ You can access the system console logs in the `/tmp/console-logs` directory. The
+
[source,terminal]
----
$ ./bin/hypershift create bastion aws --aws-creds ~/.aws/credentials --name $CLUSTER_NAME --ssh-key-file /tmp/ssh/id_rsa.pub
$ ./bin/hcp create bastion aws --aws-creds <path_to_aws_credentials_file> --name <hosted_cluster_name> --ssh-key-file <path_to_ssh_public_key>
----

.. Optional: If you used the `--generate-ssh` flag when creating the cluster, you can extract the public and private key for the cluster by running the following commands:
.. Optional: If you used the `--generate-ssh` flag when creating the cluster, you can extract the public and private key for the cluster:

... Create a directory to store the public and private SSH keys by running the following command:
+
[souce,terminal]
[source,terminal]
----
$ mkdir /tmp/ssh
$ oc get secret -n clusters ${HC_NAME}-ssh-key -o jsonpath='{ .data.id_rsa }' | base64 -d > /tmp/ssh/id_rsa
$ oc get secret -n clusters ${HC_NAME}-ssh-key -o jsonpath='{ .data.id_rsa\.pub }' | base64 -d > /tmp/ssh/id_rsa.pub
----

.. Extract journal logs from the every worker machine by running the following commands:
... Extract and store the private SSH key to the `/tmp/ssh/id_rsa` file by running the following command:
+
[source,terminal]
----
$ oc get secret -n clusters <hosted_cluster_name>-ssh-key -o jsonpath='{ .data.id_rsa }' | base64 -d > /tmp/ssh/id_rsa
----

... Extract and store the public SSH key to the `/tmp/ssh/id_rsa.pub` file by running the following command:
+
[source,terminal]
----
$ oc get secret -n clusters <hosted_cluster_name>-ssh-key -o jsonpath='{ .data.id_rsa\.pub }' | base64 -d > /tmp/ssh/id_rsa.pub
----

.. Extract journal logs from the every worker machine:

... Create a directory to store journal logs by running the following command:
+
[source,terminal]
----
$ mkdir /tmp/journals
$ INFRAID="$(oc get hc -n clusters $CLUSTER_NAME -o jsonpath='{ .spec.infraID }')"
$ SSH_PRIVATE_KEY=/tmp/ssh/id_rsa
$ ./test/e2e/util/dump/copy-machine-journals.sh /tmp/journals
----

... Extract the infrastructure ID for your hosted cluster by running the following command:
+
You must place journal logs in the `/tmp/journals` directory in a compressed format. Check for the error that indicates why kubelet did not join the cluster.
[source,terminal]
----
$ oc get hc -n clusters <hosted_cluster_name> -o jsonpath='{ .spec.infraID }'
----


You must place journal logs in the `/tmp/journals` directory in a compressed format. Check for the error that indicates why kubelet did not join the cluster.

0 comments on commit b945874

Please sign in to comment.