Kube 기본 개념을 Hands-on 실습으로 알아 보겠습니다. 실습을 위해서는 PC 환경 세팅 및 Tool 설치 등이 필요한데 해당 내용은 다음 포스트에서 다루겠습니다. 이번 장에서는 따라하시지 못하시더라도 해당 실습을 VM 환경이라면 어떻게 작업해야 할까 생각하시면서 보시면 됩니다.
1. Kubernetes에서는 Application을 POD로 관리합니다. 명령어를 사용하여 NGINX Application을 배포합니다.
[spkr@erdia22 06.Deployment (spkcluster:default)]$ k create deploy nginx --image=nginx
deployment.apps/nginx createdKube 환경에서는 이렇게 명령어를 사용하여 간단하고 빠르게 Application(nginx)을 배포하실 수 있습니다. Application은 POD 형태로 배포됩니다. (Kubernetes 환경에서 POD를 실행하는 방법이 몇가지 있는데 그 중 Deployment(번역하지만 배포 정도)를 가장 많이 사용합니다.) 그럼, 설치된 POD 리스트를 확인 합니다.
[spkr@erdia22 ~ (spkn02:nginx)]$ k get pod
NAME READY STATUS RESTARTS AGE
nginx-6799fc88d8-rk4lj 1/1 Running 0 62s약 10초 내외로 NGINX WEB Server가 설치 및 실행 되었습니다. 기존 VM 환경과 비교해보면 속도 차이를 느낄 수 있습니다. (VM 작업 시 개별 서버 ssh 접속, OS 버전에 따른 package 선택, yum -y install nginx 파일 받아서 설치 및 실행 하는등)
2. POD 개수를 50개로 증가 하세요
[spkr@erdia22 06.Deployment (spkcluster:default)]$ k scale deployment nginx --replicas=50
deployment.apps/nginx scaled
[spkr@erdia22 06.Deployment (spkcluster:default)]$ k get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-6f657c7746-4kq8m 1/1 Running 0 2m45s 10.10.100.32 dia02 <none> <none>
nginx-6f657c7746-78v88 1/1 Running 0 32s 10.10.100.45 dia02 <none> <none>
nginx-6f657c7746-7bgwr 1/1 Running 0 32s 10.10.100.47 dia01 <none> <none>
(이하 생략)위와 같이 POD 증설(Application 확장)이 굉장히 빠르고 간편합니다. 만약 VM 환경에 웹서버 50개를 설치한다고 하면 시간이 많이 걸릴 것 입니다. 아마도 1개를 배포하는 시간과 50개를 배포하는 시간이 거의 선형적으로 비례하여 약 50배 소요되겠죠. 반복 작업이라 당연히 작업 시 Human Error가 발생할 가능성이 높습니다.
이에 반하여 Kube는 여러 대의 서버를 하나의 큰 클러스터로 묶어주는 작업이 기본 기능입니다. Application 확장 작업이 필요하면 Kubernetes에서 자동적으로 여러 대의 서버에 분산하여 실행합니다. 개별 서버에 작업하는 것이 아니라 하나의 명령만 실행하면 나머지 분산 실행하는 작업은 Kubernetes가 자동으로 수행합니다.
위 그림과 같이 컨테이너를 여러 대의 화물선에 선적한다고 비유 보시면 좀 더 이해가 편하실 수 있습니다. 중앙에 있는 컨테이너 크레인이 여러 대의 컨테이너 화물선에 각각의 컨테이너를 선적합니다. 관리자는 개별 화물선에 작업을 하는 것이 아니라 중앙에 있는 컨트롤러에만 작업을 하면 됩니다. 이를 위하여 현재 컨테이너의 무게, 도착 위치, 화물의 중요도 및 개별 화물선의 현재 수용 가능한 컨테이너 수량 등의 각종 정보를 실시간으로 정보를 수집하고 조회하는 행위가 필요합니다. 이와 유사한 중앙 관리 행위를 Kubernetes가 알아서 합니다.
POD의 CPU, MEMORY 요구 사항 및 물리 노드의 현재 자원 여유량에 따라 Kubernetes는 POD를 각 노드에 할당 합니다.
위 그림에서 CPU 10 Core가 필요한 POD는 16 Core 여유가 있는 Node에 자동으로 할당 됩니다. cpu 이 외 memory + disk, network, GPU 등의 요구 사항을 사용자가 지정 할 수 있습니다.
3. POD를 삭제해 보세요.
먼저, 편의를 위하여 먼저 POD 개수(replica)를 2개로 줄여 줍니다.
[spkr@erdia22 06.Deployment (spkcluster:default)]$ k scale deployment nginx --replicas=2
deployment.apps/nginx scaledPOD 삭제는 Delete 명령어를 사용합니다.
[spkr@erdia22 06.Deployment (spkcluster:default)]$ k get pod
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-6f657c7746-r7b9b 1/1 Running 0 12m 10.10.100.25 dia04 <none> <none>
nginx-6f657c7746-zrvhv 1/1 Running 0 12m 10.10.100.43 dia04 <none> <none>
[spkr@erdia22 06.Deployment (spkcluster:default)]$ k delete pod nginx-6f657c7746-r7b9b
pod "nginx-6f657c7746-r7b9b" deleted파드를 삭제하였으나 곧 다른 POD가 자동으로 생성됩니다.
[spkr@erdia22 06.Deployment (spkcluster:default)]$ k get pod
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-6f657c7746-ckdbb 1/1 Running 0 49s 10.10.100.26 dia02 <none> <none>
nginx-6f657c7746-zrvhv 1/1 Running 0 13m 10.10.100.43 dia04 <none> <none>위와 같이 Kubernetes 항상 선언된 상태(--replica=2)를 유지 합니다. (아래에 자세히 다루어 보겠습니다.)
4. Kubernetes 기본 구조에 대하여 알아 봅시다.
앞서 언급하였듯이 항구에서 화물선에 컨테이너 선적하는 것과 유사하다고 생각하시면 조금 더 도움이 됩니다. 컨테이너를 관리 하듯이 Master Node에는 모든 정보를 저장하는 Database(etcd), 작업 커뮤니케이션이 이루어지는 Api Server(무전기), 실제 작업을 수행하는 Scheduler(크레인), 각 노드의 상태를 관리하는 controller-manager가 필수 요소 입니다.
Master Node 확인
[spkr@erdia22 ~ (spkn02:nginx)]$ k get nodes
NAME STATUS ROLES AGE VERSION
node1 Ready control-plane,master 85d v1.20.4
node2 Ready control-plane,master 85d v1.20.4
node3 Ready control-plane,master 85d v1.20.4
(master node에 taint 풀어서 worker node 용도로도 같이 사용하고 있습니다.)Controller POD 확인
[spkr@erdia22 ~ (spkn02:nginx)]$ k get pod -n kube-system
NAME READY STATUS RESTARTS AGE
calico-kube-controllers-596bd759d5-x9ztv 1/1 Running 3 85d
calico-node-7pmmz 1/1 Running 2 85d
calico-node-bct2v 1/1 Running 3 85d
calico-node-d6ntv 1/1 Running 4 85d
coredns-657959df74-7m87w 1/1 Running 2 85d
coredns-657959df74-xbjsd 1/1 Running 3 85d
dns-autoscaler-b5c786945-fttbz 1/1 Running 3 30d
etcd-node1 1/1 Running 3 85d
etcd-node2 1/1 Running 5 85d
etcd-node3 1/1 Running 3 85d
kube-apiserver-node1 1/1 Running 6 85d
kube-apiserver-node2 1/1 Running 9 85d
kube-apiserver-node3 1/1 Running 3 85d
kube-controller-manager-node1 1/1 Running 2 85d
kube-controller-manager-node2 1/1 Running 6 85d
kube-controller-manager-node3 1/1 Running 3 85d
kube-proxy-kgdnn 1/1 Running 3 30d
kube-proxy-m5x6r 1/1 Running 1 30d
kube-proxy-qtpgh 1/1 Running 4 30d
kube-scheduler-node1 1/1 Running 2 85d
kube-scheduler-node2 1/1 Running 6 85d
kube-scheduler-node3 1/1 Running 3 85d
metrics-server-bc4467d77-jktwl 1/1 Running 2 71d
nodelocaldns-2pxmp 1/1 Running 2 85d
nodelocaldns-n9wv4 1/1 Running 3 85d
nodelocaldns-vvrcc 1/1 Running 4 85dkube-system 이라는 네임스페이스에는 이처럼 Kubernetes 운영에 관련된 중요 POD(etcd, apiserver, controller-manager 등)등이 실행 중 입니다. Application 문제가 아닌 만약 클러스터 자체에 문제가 발생하면 위 POD의 이상 여부를 확인하는 게 빠르게 문제를 해결 할 수 있는 방법입니다.
모든 Request는 API Server를 통하여 진행 됩니다. 인증을 거친 요청은 ETCD Database에 저장되고 Master Node Scheduler 와 Worker node의 Kubelet이 상호 작용하여 실제 작업을 수행합니다.
Kubelet 확인
: kubelet은 etcd, scheduler 등과 같이 POD가 아닌 각 노드의 System Daemon 형태로 실행 중 입니다.
[spkr@node1 ~]$ systemctl status kubelet
● kubelet.service - Kubernetes Kubelet Server
Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2021-04-20 08:03:00 KST; 4 weeks 2 days ago
Docs: https://github.com/GoogleCloudPlatform/kubernetes
Main PID: 1402 (kubelet)
Tasks: 0
Memory: 128.5M
CGroup: /system.slice/kubelet.service
‣ 1402 /usr/local/bin/kubelet --logtostderr=true --v=2 --node-ip=172.17.29.161 --hostname-override=node1 --bootstrap-kubeconfig=/etc/kub...
May 20 14:02:30 node1 kubelet[1402]: I0520 14:02:30.509675 1402 setters.go:86] Using node IP: "172.17.29.161"
May 20 14:02:31 node1 kubelet[1402]: I0520 14:02:31.366240 1402 kubelet_getters.go:178] "Pod status updated" pod="kube-system/kube-apis...s=Running
May 20 14:02:31 node1 kubelet[1402]: I0520 14:02:31.366280 1402 kubelet_getters.go:178] "Pod status updated" pod="kube-system/kube-cont...s=Running
May 20 14:02:31 node1 kubelet[1402]: I0520 14:02:31.366293 1402 kubelet_getters.go:178] "Pod status updated" pod="kube-system/etcd-node...s=Running
May 20 14:02:31 node1 kubelet[1402]: I0520 14:02:31.366304 1402 kubelet_getters.go:178] "Pod status updated" pod="kube-system/kube-sche...s=Running
May 20 14:02:40 node1 kubelet[1402]: I0520 14:02:40.564934 1402 setters.go:86] Using node IP: "172.17.29.161"
May 20 14:02:50 node1 kubelet[1402]: I0520 14:02:50.607906 1402 setters.go:86] Using node IP: "172.17.29.161"
May 20 14:03:00 node1 kubelet[1402]: I0520 14:03:00.652281 1402 setters.go:86] Using node IP: "172.17.29.161"
May 20 14:03:10 node1 kubelet[1402]: I0520 14:03:10.694861 1402 setters.go:86] Using node IP: "172.17.29.161"
May 20 14:03:20 node1 kubelet[1402]: I0520 14:03:20.733261 1402 setters.go:86] Using node IP: "172.17.29.161"
Hint: Some lines were ellipsized, use -l to show in full.Kubernetes 선언형 상태 관리(가장 큰 특징)
이전 예제에서 POD를 삭제 하였지만 Deployment에 미리 선언된 POD 개수가 2개여서 POD가 삭제되어도 2개를 유지하기 위하여 자동으로 새로운 POD가 생성됩니다. 이렇게 항상 선언된 상태(desired state)를 Kubernetes는 자동으로 유지합니다. 운영자 입장에서는 처음에 잘 설정하여 서비스가 정상적이면 이 후 발생하는 문제는 Kubernetes에서 자동적으로 감지하여 처음의 정상적인 상태를 유지하려고 합니다. (저는 이러한 특성이 Kubernetes의 가장 큰 특징이라고 생각합니다.)
[spkr@erdia22 06.Deployment (spkcluster:default)]$ k delete pod nginx-6f657c7746-r7b9b
pod "nginx-6f657c7746-r7b9b" deleted
[spkr@erdia22 ~ (spkcluster:default)]$ kgpw
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-6f657c7746-ckdbb 1/1 Running 0 8m38s 10.10.100.26 dia02 <none> <none>
nginx-6f657c7746-zrvhv 1/1 Running 0 21m 10.10.100.43 dia04 <none> <none>
nginx-6f657c7746-ckdbb 1/1 Terminating 0 8m46s 10.10.100.26 dia02 <none> <none>
nginx-6f657c7746-dlz9t 0/1 Pending 0 0s <none> <none> <none> <none>
nginx-6f657c7746-dlz9t 0/1 Pending 0 0s <none> dia02 <none> <none>
nginx-6f657c7746-dlz9t 0/1 ContainerCreating 0 0s <none> dia02 <none> <none>
nginx-6f657c7746-ckdbb 0/1 Terminating 0 8m50s 10.10.100.26 dia02 <none> <none>
nginx-6f657c7746-dlz9t 1/1 Running 0 8s 10.10.100.37 dia02 <none> <none>
nginx-6f657c7746-ckdbb 0/1 Terminating 0 8m57s 10.10.100.26 dia02 <none> <none>
nginx-6f657c7746-ckdbb 0/1 Terminating 0 8m57s 10.10.100.26 dia02 <none> <none>
Kubernetes에서는 위와 같이 항상 현재의 상태를 감시(Observe)하여 현재의 상태와 사용자가 선언한 상태의 차이(Diff)를 확인합니다. 그래서 만약 차이가 발생하면 2개의 상태를 차이를 동일하게 유지하기 위해서 액션(Act)을 취합니다.
5. 간단히 POD에 알아 보겠습니다.
POD란 Kubernetes에서 사용하는 기본 Application 관리 단위 입니다. Application Process + Storage + Network 등으로 구성됩니다. 각 구성 요소를 확인해 보겠습니다.
POD IP 확인
[spkr@erdia22 ~ (kspray:default)]$ k create deploy nginx-hello --image=nginxdemos/hello
deployment.apps/nginx-hello created
[spkr@erdia22 ~ (kspray:default)]$ k get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-hello-7b9f9dd6bd-vl4lm 1/1 Running 0 23s 10.233.87.100 ksp3 <none> <none>App Process 및 Volume 확인
[spkr@erdia22 ~ (spkcluster:default)]$ k exec -it nginx-hello-8467bd599-k27hw -- sh
/ # ps aux
PID USER TIME COMMAND
1 root 0:00 nginx: master process nginx -g daemon off;
17 nginx 0:00 nginx: worker process
27 root 0:00 sh
34 root 0:00 ps aux
# df -h
Filesystem Size Used Avail Use% Mounted on
overlay 491G 15G 476G 4% /
tmpfs 64M 0 64M 0% /dev
tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup
/dev/mapper/centos-root 491G 15G 476G 4% /etc/hosts
shm 64M 0 64M 0% /dev/shm
tmpfs 7.9G 12K 7.9G 1% /run/secrets/kubernetes.io/serviceaccount
tmpfs 7.9G 0 7.9G 0% /proc/acpi
tmpfs 7.9G 0 7.9G 0% /proc/scsi
tmpfs 7.9G 0 7.9G 0% /sys/firmware
(volume 관련은 다른 장에서 좀 더 자세히 설명 하겠습니다.)
6. (명령어가 아닌) YAML File Source을 이용하여 busybox Application을 배포하세요.
busybox YAML File
apiVersion: apps/v1
kind: Deployment
metadata:
name: busybox
namespace: default
labels:
app: busybox
spec:
replicas: 1
selector:
matchLabels:
app: busybox # POD label과 일치
template:
metadata:
labels:
app: busybox # Selector label과 일치
spec:
containers:
- name: busybox
image: busybox
command:
- "/bin/sh"
- "-c"
- "sleep inf"
[spkr@erdia22 06.Deployment (spkcluster:default)]$ k apply -f busybox-deploy.yml
Kubernetes 에서는 모든 POD가 위와 같이 소스 코드(YAML 파일)에 의하여 관리 됩니다.
7. Kubectl 기본 명령어에 대하여 알아 보겠습니다. 먼저 POD 목록을 확인하는 명령어 입니다. (get)
- kubectl 기본 명령어
거의 항상 3가지 명령어를 기본 사용하게 됩니다. 순서대로 POD 생성, (k apply -f {YAML File}, 리스트 확인 (k get pod), 상세 정보 확인(k describe pod) 입니다.
k get (list 확인)
주로 k apply -f {YAML} 실행 이 후 실제 생성 여부 확인 용도로 사용 합니다. 이 후 에러가 발생한 경우 k describe 로 자세한 내역 및 k logs 통하여 로그 파일을 확인 합니다.
[spkr@erdia22 ~ (dzbumin:prometheus)]$ k get pod
NAME READY STATUS RESTARTS AGE
nginx-6f657c7746-dlz9t 1/1 Running 0 135m
nginx-6f657c7746-zrvhv 1/1 Running 0 156mIP & NODE 정보 포함 (-o wide). 참고로 모든 명령어는 Help(--help) 옵션으로 자세한 내용을 확인 가능합니다. 당연히 모든 옵션을 외우실 수 없으니 필요한 기능이 있으면 --help로 검색하시는 것을 추천 드립니다.
[spkr@erdia22 06.Deployment (spkcluster:default)]$ kgp(k get pod -o wide)
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-6f657c7746-dlz9t 1/1 Running 0 134m 10.10.100.37 dia02 <none> <none>
nginx-6f657c7746-zrvhv 1/1 Running 0 156m 10.10.100.43 dia04 <none> <none>
[spkr@erdia22 erdia (kspray:default)]$ k get --help
Display one or many resources
Prints a table of the most important information about the specified resources. You can filter the list using a label
selector and the --selector flag. If the desired resource type is namespaced you will only see results in your current
namespace unless you pass --all-namespaces.
(생략)변경 내역 추적 (-w, wait)
: POD 생성 또는 종료 시간이 길거나 상태 변화를 실시간으로 확인하는 경우 사용합니다.
[spkr@erdia22 ~ (k3s:default)]$ k delete pod nginx-6799fc88d8-sh6bx
pod "nginx-6799fc88d8-sh6bx" deleted
[spkr@erdia22 ~ (k3s:default)]$ kgpw
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-6799fc88d8-sh6bx 1/1 Running 0 9d 10.42.0.6 localhost.localdomain <none> <none>
nginx01-67fdf8d7c7-4ttvv 1/1 Running 0 8m5s 10.42.0.9 localhost.localdomain <none> <none>
nginx-6799fc88d8-jwr8w 1/1 Running 0 6m42s 10.42.0.10 localhost.localdomain <none> <none>
nginx-6799fc88d8-sh6bx 1/1 Terminating 0 9d 10.42.0.6 localhost.localdomain <none> <none>
nginx-6799fc88d8-2j9wd 0/1 Pending 0 0s <none> <none> <none> <none>
nginx-6799fc88d8-2j9wd 0/1 Pending 0 0s <none> localhost.localdomain <none> <none>
nginx-6799fc88d8-2j9wd 0/1 ContainerCreating 0 0s <none> localhost.localdomain <none> <none>
nginx-6799fc88d8-sh6bx 0/1 Terminating 0 9d 10.42.0.6 localhost.localdomain <none> <none>
nginx-6799fc88d8-2j9wd 1/1 Running 0 3s 10.42.0.59 localhost.localdomain <none> <none>
nginx-6799fc88d8-sh6bx 0/1 Terminating 0 9d 10.42.0.6 localhost.localdomain <none> <none>
nginx-6799fc88d8-sh6bx 0/1 Terminating 0 9d 10.42.0.6 localhost.localdomain <none> <none>전체 NameSpace 내역 출력(-A, all-namespaces)
[spkr@erdia22 06.Deployment (spkcluster:default)]$ kgpa (k get pod -A)
NAMESPACE NAME READY STATUS RESTARTS AGE IP
NODE NOMINATED NODE READINESS GATES
capi-webhook-system capa-controller-manager-c959974cd-wt5nv 2/2 Running 1 4d2h 10.10.100.34 dia04 <none> <none>
capi-webhook-system capi-controller-manager-897f45867-hb775 2/2 Running 1 5d 10.10.100.12 dia04 <none> <none>
8. 상세 설정 내역 확인 (describe)
POD 실행 시 에러가 발생하면 2가지 명령어, k describe 및 k logs 를 통하여 확인 합니다.
대부분의 에러가 2가지 명령어로 확인 및 조치 가능합니다. Kube의 아주 큰 장점입니다. 에러 메시지가 굉장히 직관적이라 에러 메세지 만으로 원인 파악 및 수정이 가능합니다. 또한 동일 명령어(application 별 로그 파일 위치를 암기하거나 검색하는 것이 아니라)로 모든 Application에 적용 가능하여 굉장히 편리합니다.
주로 현재 YAML 설정 내역(resource limits 등) 및 실패 시 events 로그 확인을 위하여 사용 합니다.
[spkr@erdia22 06.Deployment (spkcluster:default)]$ kubectl apply -f https://subicura.com/k8s/code/guide/index/wordpress-k8s.yml
deployment.apps/wordpress-mysql created
service/wordpress-mysql unchanged
deployment.apps/wordpress created
service/wordpress unchanged
[spkr@erdia22 06.Deployment (spkcluster:default)]$ k describe pod wordpress-mysql-97bf867b-82gcm
Name: wordpress-mysql-97bf867b-82gcm
Namespace: default
Priority: 0
Node: dia01/172.17.16.161
Start Time: Mon, 17 May 2021 13:26:30 +0900
Labels: app=wordpress
pod-template-hash=97bf867b
tier=mysql
Annotations: kubernetes.io/psp: collecting
Status: Running
IP: 10.10.100.26
IPs:
IP: 10.10.100.26
IP: 172.20.0.30
Controlled By: ReplicaSet/wordpress-mysql-97bf867b
Containers:
mysql:
Container ID: cri-o://aa713ad22a16c6f9938fd61cc0e66c86023c01201deea5b1db078d09deb55b8a
Image: mysql:5.6
Image ID: docker.io/library/mysql@sha256:0cec2428f4827e0581893af9b8d9fbfa84c3dbf2add6aabc645efa7f773bc00f
Port: 3306/TCP
Host Port: 0/TCP
State: Running
Started: Mon, 17 May 2021 13:26:32 +0900
Ready: True
Restart Count: 0
Environment:
MYSQL_ROOT_PASSWORD: password
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-2jss9 (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-2jss9:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-2jss9
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 30s
node.kubernetes.io/unreachable:NoExecute op=Exists for 30s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 38s default-scheduler Successfully assigned default/wordpress-mysql-97bf867b-82gcm to dia01
Normal Pulled 37s kubelet Container image "mysql:5.6" already present on machine
Normal Created 36s kubelet Created container mysql
Normal Started 36s kubelet Started container mysqlPOD Label, Image 정보 등의 상세 정보 확인이 가능합니다. (코드 내 굵은 글씨 강조가 안되는 것이 아쉽네요)
또한 에러 발생 시 Describe - Events에 해당 에러가 상세하게 출력 됩니다.
9. POD 로그 조회 (los)
Application 에서 발생하는 표준 stdout log 확인이 가능합니다.
[spkr@erdia22 06.Deployment (spkcluster:default)]$ k logs wordpress-b594fb87-qqlvj
WordPress not found in /var/www/html - copying now...
Complete! WordPress has been successfully copied to /var/www/html
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.10.100.32. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.10.100.32. Set the 'ServerName' directive globally to suppress this message
[Mon May 17 04:27:07.197983 2021] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.38 (Debian) PHP/7.4.13 configured -- resuming normal operations
[Mon May 17 04:27:07.198053 2021] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'일반적으로 컨테이너 이미지 생성 시 로그(error, access log 등)를 표준 출력으로 내 보내도록 설정합니다.
제약 사항으로 1) POD가 재 시작되면 이전 POD 로그 확인이 안 됩니다.
[spkr@erdia22 06.Deployment (spkcluster:default)]$ k delete pod nginx-6f657c7746-zrvhv
pod "nginx-6f657c7746-zrvhv" deleted
[spkr@erdia22 ~ (dzbumin:prometheus)]$ kgp(k get pod)
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-6f657c7746-dlz9t 1/1 Running 0 153m 10.10.100.37 dia02 <none> <none>
nginx-6f657c7746-jg9wg 1/1 Running 0 11s 10.10.100.38 dia04 <none> <none>기존 POD가 삭제되어 기존 POD가 종료된 이유를 찾을 수 없습니다.
2) 일반적으로 Default log file 사이즈는 10MB으로 10MB 초과된 log는 조회 하실 수 없습니다.
[spkr@node1 ~]$ systemctl status kubelet -l
● kubelet.service - Kubernetes Kubelet Server
Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2021-04-20 08:03:00 KST; 3 weeks 6 days ago
Docs: https://github.com/GoogleCloudPlatform/kubernetes
Main PID: 1402 (kubelet)
Tasks: 0
Memory: 128.5M
CGroup: /system.slice/kubelet.service
‣ 1402 /usr/local/bin/kubelet --logtostderr=true --v=2 --node-ip=172.17.29.161 --hostname-override=node1 --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --config=/etc/kubernetes/kubelet-config.yaml --kubeconfig=/etc/kubernetes/kubelet.conf --container-runtime=remote --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock --runtime-cgroups=/systemd/system.slice --network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin
[spkr@node1 ~]$ sudo cat /etc/kubernetes/kubelet-config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
nodeStatusUpdateFrequency: "10s"
(생략)
containerLogMaxFiles: 5
containerLogMaxSize: 10Mi
maxPods: 110- containerLogMaxSize: 10Mi 설정
이상으로 Kube 기본 명령어 및 개념에 대하여 알아 보았습니다.
참조: 김충섭 님 Kubernetes 강의 및 YouTube KodeKloud 강의 참조
기본 명령어
kubectl의 기본적인 사용법을 익힙니다.
subicura.com
'쿠버네티스 교육' 카테고리의 다른 글
| 05. Kube 교육 - YAML 기본 문법 (0) | 2021.06.04 |
|---|---|
| 04. Kube 교육 - Kube tool 이용(kctx, kns, kps, kubetail, k neat) (2) | 2021.06.04 |
| 03. Kube 교육 - PC 환경 설정 (0) | 2021.06.04 |
| 02. Kube 교육 - k3s, kubespray 설치 (0) | 2021.06.04 |
| 00. Kube 교육 - 개요 및 목차 (7) | 2021.06.04 |