이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 3. Restarting the cluster gracefully


This document describes the process to restart your cluster after a graceful shutdown.

Even though the cluster is expected to be functional after the restart, the cluster might not recover due to unexpected conditions, for example:

  • etcd data corruption during shutdown
  • Node failure due to hardware
  • Network connectivity issues

If your cluster fails to recover, follow the steps to restore to a previous cluster state.

3.1. Prerequisites

3.2. Restarting the cluster

You can restart your cluster after it has been shut down gracefully.

Prerequisites

  • You have access to the cluster as a user with the cluster-admin role.
  • This procedure assumes that you gracefully shut down the cluster.

Procedure

  1. Power on any cluster dependencies, such as external storage or an LDAP server.
  2. Start all cluster machines.

    Use the appropriate method for your cloud environment to start the machines, for example, from your cloud provider’s web console.

    Wait approximately 10 minutes before continuing to check the status of control plane nodes.

  3. Verify that all control plane nodes are ready.

    $ oc get nodes -l node-role.kubernetes.io/master

    The control plane nodes are ready if the status is Ready, as shown in the following output:

    NAME                           STATUS   ROLES                  AGE   VERSION
    ip-10-0-168-251.ec2.internal   Ready    control-plane,master   75m   v1.30.3
    ip-10-0-170-223.ec2.internal   Ready    control-plane,master   75m   v1.30.3
    ip-10-0-211-16.ec2.internal    Ready    control-plane,master   75m   v1.30.3
  4. If the control plane nodes are not ready, then check whether there are any pending certificate signing requests (CSRs) that must be approved.

    1. Get the list of current CSRs:

      $ oc get csr
    2. Review the details of a CSR to verify that it is valid:

      $ oc describe csr <csr_name> 1
      1
      <csr_name> is the name of a CSR from the list of current CSRs.
    3. Approve each valid CSR:

      $ oc adm certificate approve <csr_name>
  5. After the control plane nodes are ready, verify that all worker nodes are ready.

    $ oc get nodes -l node-role.kubernetes.io/worker

    The worker nodes are ready if the status is Ready, as shown in the following output:

    NAME                           STATUS   ROLES    AGE   VERSION
    ip-10-0-179-95.ec2.internal    Ready    worker   64m   v1.30.3
    ip-10-0-182-134.ec2.internal   Ready    worker   64m   v1.30.3
    ip-10-0-250-100.ec2.internal   Ready    worker   64m   v1.30.3
  6. If the worker nodes are not ready, then check whether there are any pending certificate signing requests (CSRs) that must be approved.

    1. Get the list of current CSRs:

      $ oc get csr
    2. Review the details of a CSR to verify that it is valid:

      $ oc describe csr <csr_name> 1
      1
      <csr_name> is the name of a CSR from the list of current CSRs.
    3. Approve each valid CSR:

      $ oc adm certificate approve <csr_name>
  7. After the control plane and worker nodes are ready, mark all the nodes in the cluster as schedulable. Run the following command:

    for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do echo ${node} ; oc adm uncordon ${node} ; done
  8. Verify that the cluster started properly.

    1. Check that there are no degraded cluster Operators.

      $ oc get clusteroperators

      Check that there are no cluster Operators with the DEGRADED condition set to True.

      NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
      authentication                             4.17.0    True        False         False      59m
      cloud-credential                           4.17.0    True        False         False      85m
      cluster-autoscaler                         4.17.0    True        False         False      73m
      config-operator                            4.17.0    True        False         False      73m
      console                                    4.17.0    True        False         False      62m
      csi-snapshot-controller                    4.17.0    True        False         False      66m
      dns                                        4.17.0    True        False         False      76m
      etcd                                       4.17.0    True        False         False      76m
      ...
    2. Check that all nodes are in the Ready state:

      $ oc get nodes

      Check that the status for all nodes is Ready.

      NAME                           STATUS   ROLES                  AGE   VERSION
      ip-10-0-168-251.ec2.internal   Ready    control-plane,master   82m   v1.30.3
      ip-10-0-170-223.ec2.internal   Ready    control-plane.master   82m   v1.30.3
      ip-10-0-179-95.ec2.internal    Ready    worker                 70m   v1.30.3
      ip-10-0-182-134.ec2.internal   Ready    worker                 70m   v1.30.3
      ip-10-0-211-16.ec2.internal    Ready    control-plane,master   82m   v1.30.3
      ip-10-0-250-100.ec2.internal   Ready    worker                 69m   v1.30.3

      If the cluster did not start properly, you might need to restore your cluster using an etcd backup.

Additional resources

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.