Skip to content

Latest commit

 

History

History
93 lines (65 loc) · 4.17 KB

stop-start-cluster.md

File metadata and controls

93 lines (65 loc) · 4.17 KB
Raw

Stopping and Starting a cluster

This document describes the Ansible method for restarting a k3s cluster deployed by this role.

Assumptions

It is assumed that you have already deployed a k3s cluster using this role, you have an appropriately configured inventory and playbook to create the cluster.

Below, our example inventory and playbook are as follows:

  • inventory: inventory.yml
  • playbook: cluster.yml

Method

Start cluster

You can start the cluster using either of the following commands:

  • Using the playbook: ansible-playbook -i inventory.yml cluster.yml --become -e 'k3s_state=started'
  • Using an ad-hoc command: ansible -i inventory.yml -m service -a 'name=k3s state=started' --become all

Below is example output, remember that Ansible is idempotent so re-running a command may not necessarily change the state.

Playbook method output:

PLAY RECAP *******************************************************************************************************
kube-0                     : ok=6    changed=0    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0
kube-1                     : ok=6    changed=0    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0
kube-2                     : ok=6    changed=0    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0

Stop cluster

You can stop the cluster using either of the following commands:

  • Using the playbook: ansible-playbook -i inventory.yml cluster.yml --become -e 'k3s_state=stopped'
  • Using an ad-hoc command: ansible -i inventory.yml -m service -a 'name=k3s state=stopped' --become all

Below is example output, remember that Ansible is idempotent so re-running a command may not necessarily change the state.

Playbook method output:

PLAY RECAP *******************************************************************************************************
kube-0                     : ok=6    changed=1    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0
kube-1                     : ok=6    changed=1    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0
kube-2                     : ok=6    changed=1    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0

Restart cluster

Just like the service module, you can also specify restarted as a state. This will do stop followed by start.

  • Using the playbook: ansible-playbook -i inventory.yml cluster.yml --become -e 'k3s_state=restarted'
  • Using an ad-hoc command: ansible -i inventory.yml -m service -a 'name=k3s state=restarted' --become all
PLAY RECAP *******************************************************************************************************
kube-0                     : ok=7    changed=1    unreachable=0    failed=0    skipped=3    rescued=0    ignored=0
kube-1                     : ok=7    changed=1    unreachable=0    failed=0    skipped=3    rescued=0    ignored=0
kube-2                     : ok=7    changed=1    unreachable=0    failed=0    skipped=3    rescued=0    ignored=0

Tips

You can limit the targets by adding the -l flag to your ansible-playbook command, or simply target your ad-hoc commands. For example, in a 3 node cluster (called kube-0, kube-1 and kube-2) we can limit the restart to kube-1 and kube-2 with the following:

  • Using the playbook: ansible-playbook -i inventory.yml cluster.yml --become -e 'k3s_state=restarted' -l "kube-1,kube-2"
  • Using an ad-hoc command: ansible -i inventory.yml -m service -a 'name=k3s state=restarted' --become "kube-1,kube-2"
PLAY RECAP ********************************************************************************************************
kube-1                     : ok=7    changed=2    unreachable=0    failed=0    skipped=3    rescued=0    ignored=0
kube-2                     : ok=7    changed=2    unreachable=0    failed=0    skipped=3    rescued=0    ignored=0

FAQ

  1. Why might I use the ansible-playbook command over an ad-hoc command?
    • The stop/start tasks will be aware of configuration. As the role develops, there might be some pre-tasks added to change how a cluster is stopped or started.