controlplane ~ ➜ kubectl get nodes
NAME STATUS ROLES AGE VERSION
controlplane Ready control-plane 116m v1.25.0
node01 Ready <none> 116m v1.25.0
controlplane ~ ➜
★ 클러스터를 업그레이드하는 작업을 수행해야 합니다. 애플리케이션에 접속하는 사용자에게 영향을 미치지 않아야 하며 새 VM을 프로비저닝할 수 없습니다. 클러스터를 업그레이드하기 위해 어떤 방법을 사용하시겠습니까?
-> Worker node를 다른 노드로 이동하면서 한 번에 한 노드씩 업그레이드
★ 현재 쿠버네티스의 안정적인 최신 버전은 무엇인가요?
-> v1.27.2
controlplane ~ ➜ kubeadm upgrade plan
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[preflight] Running pre-flight checks.
[upgrade] Running cluster health checks
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.25.0
[upgrade/versions] kubeadm version: v1.25.0
I0519 23:10:12.713401 17274 version.go:256] remote version is much newer: v1.27.2; falling back to: stable-1.25
[upgrade/versions] Target version: v1.25.10
[upgrade/versions] Latest version in the v1.25 series: v1.25.10
★ 현재 버전의 kubeadm 도구가 설치된 상태에서 업그레이드할 수 있는 최신 버전은 무엇인가요?
-> v1.25.10
controlplane ~ ➜ kubeadm upgrade plan
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[preflight] Running pre-flight checks.
[upgrade] Running cluster health checks
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.25.0
[upgrade/versions] kubeadm version: v1.25.0
I0519 23:10:12.713401 17274 version.go:256] remote version is much newer: v1.27.2; falling back to: stable-1.25
[upgrade/versions] Target version: v1.25.10
[upgrade/versions] Latest version in the v1.25 series: v1.25.10
Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT CURRENT TARGET
kubelet 2 x v1.25.0 v1.25.10
Upgrade to the latest version in the v1.25 series:
COMPONENT CURRENT TARGET
kube-apiserver v1.25.0 v1.25.10
kube-controller-manager v1.25.0 v1.25.10
kube-scheduler v1.25.0 v1.25.10
kube-proxy v1.25.0 v1.25.10
CoreDNS v1.9.3 v1.9.3
etcd 3.5.4-0 3.5.4-0
You can now apply the upgrade by executing the following command:
kubeadm upgrade apply v1.25.10
Note: Before you can perform this upgrade, you have to update kubeadm to v1.25.10.
controlplane ~ ➜ kubectl get nodes
NAME STATUS ROLES AGE VERSION
controlplane Ready control-plane 17m v1.26.0
node01 Ready <none> 17m v1.26.0
controlplane ~ ➜
★ namespace가 default인 deploy를 찾아라
controlplane ~ ➜ kubectl get deployments.apps --namespace default
NAME READY UP-TO-DATE AVAILABLE AGE
blue 3/3 3 3 33s
controlplane ~ ➜
★ node관리를 위해 node01을 제거해야 한다. 애플리케이션의 노드를 비우고 예약 불가능으로 표시해주세요.
초기화 컨테이너는 파드의 앱 컨테이너들이 실행되기 전에 실행되는 특수한 컨테이너이다. 초기화 컨테이너는 앱 이미지에는 없는 유틸리티 또는 설정 스크립트 등을 포함할 수 있다.
초기화 컨테이너는 containers 배열(앱 컨테이너를 기술하는)과 나란히 파드 스펙에 명시할 수 있다.
init 컨테이너 이해하기
파드는 앱들을 실행하는 다수의 컨테이너를 포함할 수 있고, 또한 앱 컨테이너 실행 전에 동작되는 하나 이상의 초기화 컨테이너도 포함할 수 있다.
다음의 경우를 제외하면, 초기화 컨테이너는 일반적인 컨테이너와 매우 유사하다.
초기화 컨테이너는 항상 완료를 목표로 실행된다.
각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다.
만약 파드의 초기화 컨테이너가 실패하면, kubelet은 초기화 컨테이너가 성공할 때까지 반복적으로 재시작한다. 그러나, 만약 파드의 restartPolicy 를 절대 하지 않음(Never)으로 설정하고, 해당 파드를 시작하는 동안 초기화 컨테이너가 실패하면, 쿠버네티스는 전체 파드를 실패한 것으로 처리한다.
컨테이너를 초기화 컨테이너로 지정하기 위해서는, 파드 스펙에 initContainers 필드를 container 항목(앱 container 필드 및 내용과 유사한)들의 배열로서 추가한다. 컨테이너에 대한 더 상세한 사항은 API 레퍼런스를 참고한다.
초기화 컨테이너의 상태는 컨테이너 상태의 배열(.status.containerStatuses 필드와 유사)로 .status.initContainerStatuses 필드에 반환된다.
일반적인 컨테이너와의 차이점
초기화 컨테이너는 앱 컨테이너의 리소스 상한(limit), 볼륨, 보안 세팅을 포함한 모든 필드와 기능을 지원한다. 그러나, 초기화 컨테이너를 위한 리소스 요청량과 상한은 리소스에 문서화된 것처럼 다르게 처리된다.
또한, 초기화 컨테이너는 lifecycle, livenessProbe, readinessProbe 또는 startupProbe 를 지원하지 않는다. 왜냐하면 초기화 컨테이너는 파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기 때문이다.
만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, kubelet은 해당 초기화 컨테이너들을 한 번에 하나씩 실행한다. 각 초기화 컨테이너는 다음 컨테이너를 실행하기 전에 꼭 성공해야 한다. 모든 초기화 컨테이너들이 실행 완료되었을 때, kubelet은 파드의 애플리케이션 컨테이너들을 초기화하고 평소와 같이 실행한다
init 컨테이너를 이용하여 pod 생성
# YAML 파일을 이용하여 init 컨테이너 생성
master@master:~$ cat init-container.yaml
apiVersion: v1
kind: Pod
metadata:
name: init-container
spec:
containers:
- name: busybox
image: k8s.gcr.io/busybox
command: [ "ls" ]
args: [ "/work-dir/moby" ]
volumeMounts:
- name: workdir
mountPath: /work-dir
initContainers:
- name: git
image: alpine/git
command: ["sh"]
args:
- "-c"
- "git clone https://github.com/moby/moby.git \
/work-dir/moby"
volumeMounts:
- name: workdir
mountPath: "/work-dir"
volumes:
- name: workdir
emptyDir: {}
master@master:~$
master@master:~$ kubectl apply -f init-container.yaml
pod/init-container created
master@master:~$
master@master:~$ kubectl get pod
NAME READY STATUS RESTARTS AGE
init-container 0/1 Init:0/1 0 10s
master@master:~$
master@master:~$ kubectl logs init-container
Error from server (BadRequest): container "busybox" in pod "init-container" is waiting to start: PodInitializing
master@master:~$ kubectl logs init-container -c git
Cloning into '/work-dir/moby'...
master@master:~$ kubectl logs init-container -c git -f
Cloning into '/work-dir/moby'...
Updating files: 100% (7258/7258), done.
master@master:~$
master@master:~$ kubectl logs init-container
AUTHORS
CHANGELOG.md
CONTRIBUTING.md
Dockerfile
Dockerfile.e2e
Dockerfile.simple
Dockerfile.windows
Jenkinsfile
LICENSE
MAINTAINERS
Makefile
NOTICE
README.md
ROADMAP.md
SECURITY.md
TESTING.md
VENDORING.md
api
builder
cli
client
cmd
codecov.yml
container
contrib
daemon
distribution
docker-bake.hcl
dockerversion
docs
errdefs
hack
image
integration
integration-cli
internal
layer
libcontainerd
libnetwork
oci
opts
pkg
plugin
profiles
project
quota
reference
registry
reports
restartmanager
rootless
runconfig
testutil
vendor
vendor.mod
vendor.sum
volume
master@master:~$
YAML파일안에 sleep 5초를 준 이유는 Pod 안에 컨테이너가 동시에 시작되면 nginx 컨테이너에 오류가 발생할 수 있기에 mynginx 컨테이너 먼저 러닝상태가 되면 jinsunginx 컨테이너가 동작할 수 있게 옵션을 준 것입니다.
# 파드안에 두개의 컨테이너 생성하는 YAML파일 생성
master@master:~$ cat two-container.yaml
apiVersion: v1
kind: Pod
metadata:
name: mynginx
spec:
containers:
- name: mynginx
image: nginx
- name: jinsunginx
image: curlimages/curl
command: ["sh"]
args:
- "-c"
- "sleep 5 && curl localhost"
master@master:~$
master@master:~$ kubectl apply -f two-container.yaml
pod/mynginx created
master@master:~$
master@master:~$ kubectl get pod
NAME READY STATUS RESTARTS AGE
mynginx 1/2 Running 0 18s
master@master:~$
# 그냥 pod의 logs를 조회하면 컨테이너를 선택하라는 문구가 나온다.
master@master:~$ kubectl logs mynginx
error: a container name must be specified for pod mynginx, choose one of: [mynginx jinsunginx]
# 두개의 컨테이너가 있을떄는 -c 옵션을 사용한다.
master@master:~$ kubectl logs mynginx -c mynginx
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2022/08/09 12:59:15 [notice] 1#1: using the "epoll" event method
2022/08/09 12:59:15 [notice] 1#1: nginx/1.23.1
2022/08/09 12:59:15 [notice] 1#1: built by gcc 10.2.1 20210110 (Debian 10.2.1-6)
2022/08/09 12:59:15 [notice] 1#1: OS: Linux 4.15.0-189-generic
2022/08/09 12:59:15 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2022/08/09 12:59:15 [notice] 1#1: start worker processes
2022/08/09 12:59:15 [notice] 1#1: start worker process 32
2022/08/09 12:59:15 [notice] 1#1: start worker process 33
2022/08/09 12:59:15 [notice] 1#1: start worker process 34
2022/08/09 12:59:15 [notice] 1#1: start worker process 35
127.0.0.1 - - [09/Aug/2022:12:59:28 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.84.0-DEV" "-"
127.0.0.1 - - [09/Aug/2022:12:59:36 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.84.0-DEV" "-"
127.0.0.1 - - [09/Aug/2022:12:59:58 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.84.0-DEV" "-"
master@master:~$
master@master:~$ kubectl logs mynginx
error: a container name must be specified for pod mynginx, choose one of: [mynginx jinsunginx]
master@master:~$ kubectl logs mynginx -c jinsunginx
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 615 100 615 0 0 1002k 0 --:--:-- --:--:-- --:--:-- 600k
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
master@master:~$
