diff --git a/hosted_control_planes/hcp-getting-started.adoc b/hosted_control_planes/hcp-getting-started.adoc index 90a4559f1654..328435b689c1 100644 --- a/hosted_control_planes/hcp-getting-started.adoc +++ b/hosted_control_planes/hcp-getting-started.adoc @@ -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"] diff --git a/modules/debug-nodes-hcp.adoc b/modules/debug-nodes-hcp.adoc index 468bcb35320b..71a23e5fdbc0 100644 --- a/modules/debug-nodes-hcp.adoc +++ b/modules/debug-nodes-hcp.adoc @@ -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 - +---- ++ +Replace `` with your hosted cluster namespace name, for example, `clusters`. Replace `` 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: @@ -36,23 +46,32 @@ $ oc get hc -n -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 +---- + +. 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 ---- -. 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 +---- + +. If worker machines do not exist, check if the `machineset` resources are created by running the following command: ++ +[source,terminal] +---- +$ oc get machineset -n ---- . If the `machinedeployment` and `machineset` resources do not exist, check logs of the HyperShift Operator by running the following command: @@ -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 ---- . 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 --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`. @@ -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 --name --ssh-key-file ---- -.. 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 -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 -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. \ No newline at end of file +[source,terminal] +---- +$ oc get hc -n clusters -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.