gha: kata-deploy: Add containerd status check

After kata-deploy has installed, check that the worker nodes
are still in Ready state and don't have a containerd://Unknown
container runtime versions, identicating that container isn't working
to ensure that we didn't corrupt the containerd config during kata-deploy's edits

Fixes: #8678
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
This commit is contained in:
stevenhorsman 2023-12-15 14:04:30 +00:00
parent 7e5868a55f
commit 9e718b4e23

View File

@ -64,7 +64,7 @@ setup() {
sleep 30s
}
@test "Test runtimeclasses are being properly created" {
@test "Test runtimeclasses are being properly created and container runtime not broken" {
# We filter `kata-mshv-vm-isolation` out as that's present on AKS clusters, but that's not coming from kata-deploy
current_runtime_classes=$(kubectl get runtimeclasses | grep -v "kata-mshv-vm-isolation" | grep "kata" | wc -l)
[[ ${current_runtime_classes} -eq ${expected_runtime_classes} ]]
@ -73,6 +73,20 @@ setup() {
do
kubectl get runtimeclass | grep -E "${handler_re}"
done
# Ensure that kata-deploy didn't corrupt containerd config, by trying to get the container runtime and node status
echo "::group::kubectl node debug"
kubectl get node -o wide
kubectl describe nodes
echo "::endgroup::"
# Wait to see if the nodes get back into Ready state - if not then containerd might be having issues
kubectl wait nodes --timeout=60s --all --for condition=Ready=True
# Check that the container runtime verison doesn't have unknown, which happens when containerd can't start properly
container_runtime_version=$(kubectl get nodes --no-headers -o custom-columns=CONTAINER_RUNTIME:.status.nodeInfo.containerRuntimeVersion)
[[ ${container_runtime_version} != *"containerd://Unknown"* ]]
}
teardown() {