docker pull 로 이미지를 docker hub 에서 받아올 때 아래와 같이 에러가 나며 실패하는 경우가 있다.

$ docker pull centos:6
Error response from daemon: no matching manifest for linux/arm64/v8 in the manifest list entries: no match for platform in manifest: not found

해당 태그(6)의 이미지가 없기 때문인데, 사용 가능한 태그 목록을 조회하기 위해 docker hub 웹사이트에 접속한다.

docker hub 웹사이트에서 원하는 이미지를 찾아 들어가면 Tag summary 에서 인기있는 주요 태그들을 볼 수있다.(권장하는 태그들)

그리고, Tag 탭을 통해 들어가면 docker hub 에 push 된 모든 태그를 볼 수 있다. 하지만 페이지네이션 때문에 한번에 모든 태그를 볼 수가 없다.

(Tag summary 에 노출되는 기준은 Tags 에서 확인할 수 있는 태그 목록의 newest 내림차순 10개인 것 같다.)

웹사이트에 방문하지 않고 다음 커맨드로도 조회할 수 있다.

$ curl -s "https://registry.hub.docker.com/v2/repositories/library/centos/tags/" | jq '.results[].name'

하지만, page_size 파라미터 기본값이 10이고, 최대값이 100 이기 때문에, nginx 나 ubuntu 와 같이 태그가 엄청나게 많은 경우에는 최대 100개까지밖에 조회가 안된다.(docker 의 정책이다) 따라서, 모든 태그를 조회하기 위해 아래 스크립트를 실행하면 된다. 각 fetch 의 응답필드 중 next 에 명시된 url 을 추가 호출하는 방식이다.

fetch-docker-hub-all-tags.sh

#!/bin/bash

# 인자 확인
if [ -z "$1" ]; then
  echo "사용법: $0 <repository-name>"
  echo "예시: $0 ubuntu"
  exit 1
fi

REPO="$1"
URL="https://registry.hub.docker.com/v2/repositories/library/${REPO}/tags?page_size=100"

while [ "$URL" != "null" ]; do
  RESP=$(curl -s "$URL")
  echo "$RESP" | jq -r '.results[].name'
  URL=$(echo "$RESP" | jq -r '.next')
done

이를 다음과 같이 이미지명을 파라미터로 주입하여 실행하면 모든 태그를 조회할 수 있다.

$ sh fetch-docker-hub-all-tags.sh centos
$ sh fetch-docker-hub-all-tags.sh ubuntu
$ sh fetch-docker-hub-all-tags.sh nginx

스테이트풀셋을 삭제한 경우에는(kubectl delete -f 든, kubectl delete sts 든) PV, PVC 는 삭제되지 않고 남아있게 되며, PVC 와 PV 의 바인딩 관계도 그대로 유지되게 된다. 때문에 다시 스테이트풀셋을 생성한 경우에 남아있던 영구 볼륨 데이터 그대로 파드가 기동되어 재사용하게 된다. 레플리카수를 scale in 하였다가 다시 scale out 한 경우도 마찬가지로 동작한다.

$ kubectl apply -f sample-statefulset.yaml
$ kubectl get pv
$ kubectl get pvc

# sample-statefulset 을 수동으로 삭제한 후에도 PV, PVC 가 유지되는지 확인

$ kubectl delete statefulset sample-statefulset
$ kubectl get pv
$ kubectl get pvc

직접 PVC 를 삭제하면, PV 와 바인딩이 풀리면서 PV 도 자동으로 삭제되게 된다.(영구볼륨의 ClaimPolicy 설정 기본값일 때)

$ kubectl delete pvc www-statefulset-{0..2}

데몬셋과 동일하게 OnDelete, RollingUpdate 를 지정할 수 있지만 몇가지 차이점이 있다.

1. RollingUpdate 시 데몬셋과 다른 점

OnDelete 는 데몬셋의 그것과 동일하게 동작하지만, RollingUpdate 의 경우에는 좀 다르다. 스테이트풀셋은 영속성 데이터를 다루는 리소스 컨트롤러 이므로, 추가 파드를 생성해서 롤링 업데이트를 할 수 없으며, 마찬가지로 maxUnavailable 를 지정하여 업데이트 중 동시에 여러 파드를 중지시킬 수도 없다. 파드마다 ready 상태 여부를 확인하고 순차적으로 업데이트하게 된다.(spec.podManagementPolicy: Parallel 이어도 마찬가지)

2. RollingUpdate 시 파티션을 나누어 업데이트

스테이트풀셋의 경우 spec.updateStrategy.rollingUpdate.partition 필드에 RollingUpdate 를 적용할 파티션을 지정할 수 있다.(아래 참고) partition 을 설정하면, 해당 값 이상의 인덱스 값을 가진 파드들만 업데이트 대상이 된다. 수동으로 재기동한 경우에도 partition 의 영향을 받는다.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: statefulset-rollingupdate
spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      partition: 3
  serviceName: statefulset-rollingupdate
  replicas: 5
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
        - name: nginx-container
          image: nginx:1.16

위 매니페스트를 사용하여 스테이트풀셋을 만들고, 파드를 업데이트하면서 관찰해보면, 실제로 partition 에 해당하는 인덱스 이상의 파드만 업데이트 되는 것을 볼 수 있다.

$ kubectl apply -f statefulset-rollingupdate.yaml
# statefulset-rollingupdate-0 ~ 4 까지 5개의 파드가 순차적으로 생성됨

# nginx:1.16 -> nginx:1.17 로 이미지 수정 후 다시 apply 를 진행
# watch 를 이용하여 파드 상태를 관찰하면 아래와 같이 출력됨
$ kubectl get pods -l app=sample-app -o wide --watch
NAME                          READY   STATUS              RESTARTS   AGE   IP            NODE              NOMINATED NODE   READINESS GATES
statefulset-rollingupdate-4   1/1     Terminating         0          83s   10.244.2.11   desktop-worker2   <none>           <none>
statefulset-rollingupdate-4   0/1     Completed           0          83s   10.244.2.11   desktop-worker2   <none>           <none>
statefulset-rollingupdate-4   0/1     Completed           0          84s   10.244.2.11   desktop-worker2   <none>           <none>
statefulset-rollingupdate-4   0/1     Completed           0          84s   10.244.2.11   desktop-worker2   <none>           <none>
statefulset-rollingupdate-4   0/1     Pending             0          0s    <none>        <none>            <none>           <none>
statefulset-rollingupdate-4   0/1     Pending             0          0s    <none>        desktop-worker2   <none>           <none>
statefulset-rollingupdate-4   0/1     ContainerCreating   0          0s    <none>        desktop-worker2   <none>           <none>
statefulset-rollingupdate-4   1/1     Running             0          1s    10.244.2.12   desktop-worker2   <none>           <none>
statefulset-rollingupdate-3   1/1     Terminating         0          86s   10.244.2.10   desktop-worker2   <none>           <none>
statefulset-rollingupdate-3   1/1     Terminating         0          86s   10.244.2.10   desktop-worker2   <none>           <none>
statefulset-rollingupdate-3   0/1     Completed           0          86s   10.244.2.10   desktop-worker2   <none>           <none>
statefulset-rollingupdate-3   0/1     Completed           0          87s   10.244.2.10   desktop-worker2   <none>           <none>
statefulset-rollingupdate-3   0/1     Completed           0          87s   10.244.2.10   desktop-worker2   <none>           <none>
statefulset-rollingupdate-3   0/1     Pending             0          0s    <none>        <none>            <none>           <none>
statefulset-rollingupdate-3   0/1     Pending             0          0s    <none>        desktop-worker2   <none>           <none>
statefulset-rollingupdate-3   0/1     ContainerCreating   0          0s    <none>        desktop-worker2   <none>           <none>
statefulset-rollingupdate-3   1/1     Running             0          1s    10.244.2.13   desktop-worker2   <none>           <none>

즉, 0번~2번 인덱스의 파드는 영향을 받지 않고, 3~4번 인덱스의 파드가 하나씩 순차적으로 Termination -> Completed 로 종료된 후, Pending -> ContainerCreating -> Running 으로 새로 실행된 것을 알 수 있다. 여기서 이번에는 partition 을 1로 변경 후 apply 하게 되면 1~2번 파드만 추가로 업데이트를 하게 된다.(기존 업데이트 완료되었던 3~4번 파드는 업데이트되지 않음)