반응형

 

파드 및 컨테이너 리소스 관리

파드를 생성 및 지정할 때, 컨테이너에 필요한 리소스의 자원을 선택하여 지정할 수 있다. 지정할 가장 일반적인 리소스는 CPU와 메모리(RAM) 그리고 다른 것들이 있다.

파드에서 컨테이너에 대한 리소스 요청(request) 을 지정하면, kube-scheduler는 이 정보를 사용하여 파드가 배치될 노드를 결정한다. 컨테이너에 대한 리소스 제한(limit) 을 지정하면, kubelet은 실행 중인 컨테이너가 설정한 제한보다 많은 리소스를 사용할 수 없도록 해당 제한을 적용한다. 또한 kubelet은 컨테이너가 사용할 수 있도록 해당 시스템 리소스의 최소 요청 자원을 예약한다.

요청 및 제한

파드가 실행 중인 노드에 사용 가능한 리소스가 충분하면, 컨테이너가 해당 리소스에 지정한 request 보다 더 많은 리소스를 사용할 수 있도록 허용된다. 그러나, 컨테이너는 리소스 limit 보다 더 많은 리소스를 사용할 수는 없다.

예를 들어, 컨테이너에 대해 256MiB의 memory 요청을 설정하고, 해당 컨테이너가 8GiB의 메모리를 가진 노드로 스케줄된 파드에 있고 다른 파드는 없는 경우, 컨테이너는 더 많은 RAM을 사용할 수 있다.

해당 컨테이너에 대해 4GiB의 memory 제한을 설정하면, kubelet(그리고 컨테이너 런타임)이 제한을 적용한다. 런타임은 컨테이너가 구성된 리소스 제한을 초과하여 사용하지 못하게 한다. 예를 들어, 컨테이너의 프로세스가 허용된 양보다 많은 메모리를 사용하려고 하면, 시스템 커널은 메모리 부족(out of memory, OOM) 오류와 함께 할당을 시도한 프로세스를 종료한다.

제한은 반응적(시스템이 위반을 감지한 후에 개입)으로 또는 강제적(시스템이 컨테이너가 제한을 초과하지 않도록 방지)으로 구현할 수 있다. 런타임마다 다른 방식으로 동일한 제약을 구현할 수 있다.

 

파드와 컨테이너의 리소스 요청 및 제한

각 컨테이너에 대해, 다음과 같은 리소스 제한(limit) 및 요청(request)을 지정할 수 있다.

  • spec.containers[].resources.limits.cpu
  • spec.containers[].resources.limits.memory
  • spec.containers[].resources.limits.hugepages-<size>
  • spec.containers[].resources.requests.cpu
  • spec.containers[].resources.requests.memory
  • spec.containers[].resources.requests.hugepages-<size>

 

쿠버네티스의 리소스 단위

CPU 리소스 단위

CPU 리소스에 대한 제한 및 요청은 cpu 단위로 측정된다. 쿠버네티스에서, 1 CPU 단위는 노드가 물리 호스트인지 아니면 물리 호스트 내에서 실행되는 가상 머신인지에 따라 1 물리 CPU 코어 또는 1 가상 코어 에 해당한다.

요청량을 소수점 형태로 명시할 수도 있다. 컨테이너의 spec.containers[].resources.requests.cpu를 0.5로 설정한다는 것은, 1.0 CPU를 요청했을 때와 비교하여 절반의 CPU 타임을 요청한다는 의미이다. CPU 자원의 단위와 관련하여, 0.1 이라는 수량 표현은 "백 밀리cpu"로 읽을 수 있는 100m 표현과 동일하다. 어떤 사람들은 "백 밀리코어"라고 말하는데, 같은 것을 의미하는 것으로 이해된다.

CPU 리소스는 항상 리소스의 절대량으로 표시되며, 상대량으로 표시되지 않는다. 예를 들어, 컨테이너가 싱글 코어, 듀얼 코어, 또는 48 코어 머신 중 어디에서 실행되는지와 상관없이 500m CPU는 거의 같은 양의 컴퓨팅 파워를 가리킨다.

참고: 쿠버네티스에서 CPU 리소스를 1m보다 더 정밀한 단위로 표기할 수 없다. 이 때문에, CPU 단위를 1.0 또는 1000m보다 작은 밀리CPU 형태로 표기하는 것이 유용하다. 예를 들어, 0.005 보다는 5m으로 표기하는 것이 좋다.

메모리 리소스 단위

memory 에 대한 제한 및 요청은 바이트 단위로 측정된다. E, P, T, G, M, k 와 같은 수량 접미사 중 하나를 사용하여 메모리를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다.

128974848, 129e6, 129M, 128974848000m, 123Mi

접미사의 대소문자에 유의한다. 400m의 메모리를 요청하면, 이는 0.4 바이트를 요청한 것이다. 이 사람은 아마도 400 메비바이트(mebibytes) (400Mi) 또는 400 메가바이트 (400M) 를 요청하고 싶었을 것이다.

 

 

 

 

YAML을 이용하여 request 리소스 pod 생성

# reqeust 리소스를 이용하여 cpu 0.25 코어 RAM 500M 생성
master@master:~$ cat request.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: request 
spec:
  containers: 
  - name: nginx
    image: nginx
    resources:
      requests:
        cpu: 250m
        memory: 500Mi
master@master:~$

master@master:~$ kubectl apply -f request.yaml 
pod/request created
master@master:~$ 

master@master:~$ kubectl get pod
NAME           READY   STATUS    RESTARTS   AGE
volume-nginx   1/1     Running   1          2d4h
env-pod        1/1     Running   1          2d3h
request        1/1     Running   0          6s
master@master:~$ 

master@master:~$ kubectl get pod request -oyaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"request","namespace":"default"},"spec":{"containers":[{"image":"nginx","name":"nginx","resources":{"requests":{"cpu":"250m","memory":"500Mi"}}}]}}
  creationTimestamp: "2022-08-09T12:33:02Z"
  name: request
  namespace: default
  resourceVersion: "15774"
  selfLink: /api/v1/namespaces/default/pods/request
  uid: 53aec9d6-6831-4d6e-b7ff-870a35eff92a
spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: nginx
    resources:
      requests:
        cpu: 250m
        memory: 500Mi

 

 

YAML을 이용하여 limit 리소스 pod 생성

# limit 리소스를 이용하여 cpu 0.5 코어 RAM 1G 생성
master@master:~$ cat limits.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: limit 
spec:
  containers: 
  - name: nginx 
    image: nginx
    resources:
     limits:
       cpu: 500m
       memory: 1Gi
master@master:~$ 

master@master:~$ kubectl apply -f limits.yaml 
pod/limit created
master@master:~$ 

master@master:~$ kubectl get pod
NAME           READY   STATUS    RESTARTS   AGE
volume-nginx   1/1     Running   1          2d4h
env-pod        1/1     Running   1          2d4h
request        1/1     Running   0          14m
limit          1/1     Running   0          13m
master@master:~$ 

master@master:~$ kubectl get pod limit -oyaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"limit","namespace":"default"},"spec":{"containers":[{"image":"nginx","name":"nginx","resources":{"limits":{"cpu":"500m","memory":"1Gi"}}}]}}
  creationTimestamp: "2022-08-09T12:34:54Z"
  name: limit
  namespace: default
  resourceVersion: "15864"
  selfLink: /api/v1/namespaces/default/pods/limit
  uid: 25e779dd-5f44-4c14-af31-108df5f8658d
spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: nginx
    resources:
      limits:
        cpu: 500m
        memory: 1Gi
      requests:
        cpu: 500m
        memory: 1Gi

 

 

 

 

 

 

 

 

 

참고자료

https://kubernetes.io/ko/docs/concepts/configuration/manage-resources-containers/

반응형
반응형

 

 

 

매개변수로 정보 전달하기

# Pod 생성하는 YAML파일 생성
master@master:~$ cat arg-pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: arg-pod
spec:
  containers: 
  - name: ubuntu
    image: ubuntu:18.04
    command: [ "echo" ]
    args: [ "abc", "def" ]
master@master:~$ 

master@master:~$ kubectl apply -f arg-pod.yaml 
pod/arg-pod created
master@master:~$

master@master:~$ kubectl logs arg-pod     
abc def
master@master:~$

 

 

환경변수 설정하기

# pod 생성을 위한 YAML 파일 생성
master@master:~$ cat env-pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: env-pod
spec:
  containers: 
  - name: nginx
    image: nginx
    env:
    - name: my_env
      value: "this is jinsu nginx!"
master@master:~$

master@master:~$ kubectl apply -f env-pod.yaml 
pod/env-pod created
master@master:~$

master@master:~$ kubectl get pod
NAME           READY   STATUS             RESTARTS   AGE
volume-nginx   1/1     Running            0          41m
env-pod        1/1     Running            0          44s
master@master:~$

# exec 명령으로 env-pod 환경변수 확인
master@master:~$ kubectl exec env-pod -- printenv
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=env-pod
my_env=this is jinsu nginx!
KUBERNETES_PORT=tcp://10.43.0.1:443
KUBERNETES_PORT_443_TCP=tcp://10.43.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_ADDR=10.43.0.1
KUBERNETES_SERVICE_HOST=10.43.0.1
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
NGINX_VERSION=1.23.1
NJS_VERSION=0.7.6
PKG_RELEASE=1~bullseye
HOME=/root
master@master:~$

 

 

 

 

 

 

 

 

참고자료

https://kubernetes.io/ko/docs/tasks/inject-data-application/_print/

 

 

 

반응형
반응형

 

 

 

볼륨(volume)

컨테이너 내의 디스크에 있는 파일은 임시적이며, 컨테이너에서 실행될 때 애플리케이션에 적지 않은 몇 가지 문제가 발생한다. 한 가지 문제는 컨테이너가 크래시될 때 파일이 손실된다는 것이다. kubelet은 컨테이너를 다시 시작하지만 초기화된 상태이다. 두 번째 문제는 Pod에서 같이 실행되는 컨테이너간에 파일을 공유할 때 발생한다. 쿠버네티스 볼륨 추상화는 이러한 문제를 모두 해결한다. Pod에 대해 익숙해지는 것을 추천한다

 

 

 

volume-pod 생성 

# YAML파일 생성
master@master:~$ cat volume-pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: volume-nginx
spec:
  containers: 
  - name: jinsunginx
    image: nginx
    volumeMounts:
    - mountPath: /test-volume
      name: my-volume
  volumes:
  - name: my-volume
    hostPath:
      path: /home
      type: Directory
master@master:~$ 

# Pod 생성
master@master:~$ kubectl apply -f volume-pod.yaml 
pod/volume-nginx created

 

 

volume 연결 확인

# 로컬 디렉토리와 volume-nginx pod 디렉토리와 연결 확인
master@master:~$ kubectl exec volume-nginx -- ls -alh /test-volume/master
total 64K
drwxr-xr-x 6 1000 1000 4.0K Aug  7 07:54 .
drwxr-xr-x 3 root root 4.0K Aug  6 16:27 ..
-rw------- 1 1000 1000 1.2K Aug  7 07:13 .bash_history
-rw-r--r-- 1 1000 1000  220 Apr  4  2018 .bash_logout
-rw-r--r-- 1 1000 1000 3.8K Aug  7 05:36 .bashrc
drwx------ 2 1000 1000 4.0K Aug  6 16:30 .cache
drwx------ 3 1000 1000 4.0K Aug  6 16:30 .gnupg
drwxrwxr-x 4 1000 1000 4.0K Aug  7 04:38 .kube
-rw-r--r-- 1 1000 1000  807 Apr  4  2018 .profile
drwx------ 2 1000 1000 4.0K Aug  6 16:28 .ssh
-rw-r--r-- 1 1000 1000    0 Aug  7 03:44 .sudo_as_admin_successful
-rw------- 1 1000 1000 8.8K Aug  7 07:54 .viminfo
-rw-rw-r-- 1 1000 1000  155 Aug  7 07:14 jinsu2nginx.yaml
-rw-rw-r-- 1 1000 1000  137 Aug  7 06:25 jinsunginx.yaml
-rw-rw-r-- 1 1000 1000  270 Aug  7 07:54 volume-pod.yaml
master@master:~$ 

master@master:~$ ls -al
total 64
drwxr-xr-x 6 master master 4096 Aug  7 07:54 .
drwxr-xr-x 3 root   root   4096 Aug  6 16:27 ..
-rw------- 1 master master 1165 Aug  7 07:13 .bash_history
-rw-r--r-- 1 master master  220 Apr  4  2018 .bash_logout
-rw-r--r-- 1 master master 3838 Aug  7 05:36 .bashrc
drwx------ 2 master master 4096 Aug  6 16:30 .cache
drwx------ 3 master master 4096 Aug  6 16:30 .gnupg
-rw-rw-r-- 1 master master  155 Aug  7 07:14 jinsu2nginx.yaml
-rw-rw-r-- 1 master master  137 Aug  7 06:25 jinsunginx.yaml
drwxrwxr-x 4 master master 4096 Aug  7 04:38 .kube
-rw-r--r-- 1 master master  807 Apr  4  2018 .profile
drwx------ 2 master master 4096 Aug  6 16:28 .ssh
-rw-r--r-- 1 master master    0 Aug  7 03:44 .sudo_as_admin_successful
-rw------- 1 master master 8970 Aug  7 07:54 .viminfo
-rw-rw-r-- 1 master master  270 Aug  7 07:54 volume-pod.yaml
master@master:~$

 

 

 

 

참고자료

https://kubernetes.io/ko/docs/concepts/storage/volumes/

반응형
반응형

레이블과 셀렉터

레이블은 Pod와 같은 오브젝트에 첨부된 키와 값의 쌍이다. 레이블은 오브젝트의 특성을 식별하는 데 사용되어 사용자에게 중요하지만, 코어 시스템에 직접적인 의미는 없다. 레이블로 오브젝트의 하위 집합을 선택하고, 구성하는데 사용할 수 있다. 레이블은 오브젝트를 생성할 때에 붙이거나 생성 이후에 붙이거나 언제든지 수정이 가능하다. 오브젝트마다 키와 값으로 레이블을 정의할 수 있다. 오브젝트의 키는 고유한 값이어야 한다.

"metadata": {
  "labels": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 어노테이션으로 기록해야 한다.

 

사용 동기

레이블을 이용하면 사용자가 간단하게 결합한 방식으로 조직 구조와 시스템 오브젝트를 매핑할 수 있으며, 클라이언트에 매핑 정보를 저장할 필요가 없다.

 

레이블 셀렉터

이름과 UID와 다르게 레이블은 고유하지 않다. 일반적으로 우리는 많은 오브젝트에 같은 레이블을 사용한다.

레이블 셀렉터를 통해 클라이언트와 사용자는 오브젝트를 식별할 수 있다. 레이블 셀렉터는 쿠버네티스 코어 그룹의 기본이다.

API는 현재 일치성 기준 과 집합성 기준 이라는 두 종류의 셀렉터를 지원한다. 레이블 셀렉터는 쉼표로 구분된 다양한 요구사항 에 따라 만들 수 있다. 다양한 요구사항이 있는 경우 쉼표 기호가 AND(&&) 연산자로 구분되는 역할을 하도록 해야 한다.

비어있거나 지정되지 않은 셀렉터는 상황에 따라 달라진다. 셀렉터를 사용하는 API 유형은 유효성과 의미를 따로 정의하여 정리해야 한다.

참고: 레플리카셋(ReplicaSet)과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
주의: 일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 OR (||) 연산자가 없다. 필터 구문이 적절히 구성되어 있는지 확인해야 한다.

 

labels 확인 

master@master:~$ kubectl get pod
NAME          READY   STATUS    RESTARTS   AGE
jinsunginx    1/1     Running   0          9s
jinsu2nginx   1/1     Running   0          9s
master@master:~$ 

master@master:~$ kubectl get pod -L run
NAME          READY   STATUS    RESTARTS   AGE     RUN
jinsunginx    1/1     Running   0          2m58s   jinsunginx
jinsu2nginx   1/1     Running   0          2m58s   jinsu2nginx
master@master:~$ 

master@master:~$ kubectl get pod jinsunginx --show-labels
NAME         READY   STATUS    RESTARTS   AGE     LABELS
jinsunginx   1/1     Running   0          3m21s   run=jinsunginx
master@master:~$

 

 

labels 추가 및 확인

# color를 red로 labels 설정
master@master:~$ cat jinsu2nginx.yaml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: jinsu2nginx
    color: red 
  name: jinsu2nginx
spec:
  containers:
  - name: nginx
    image: nginx
master@master:~$

# labels 확인
master@master:~$ kubectl get pod jinsu2nginx --show-labels
NAME          READY   STATUS    RESTARTS   AGE   LABELS
jinsu2nginx   1/1     Running   0          27s   color=red,run=jinsu2nginx
master@master:~$

 

 

Pod edit으로 labels 수정

# kubectl edit pod로 color 오렌지색으로 labels 수정
master@master:~$ kubectl edit pod jinsunginx
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"labels":{"run":"jinsunginx"},"name":"jinsunginx","names
  creationTimestamp: "2022-08-07T07:08:05Z"
  labels:
    color: orange
    run: jinsunginx
  name: jinsunginx
  namespace: default
  resourceVersion: "7343"
  selfLink: /api/v1/namespaces/default/pods/jinsunginx
  uid: 22d83e8b-4d1e-4072-a09c-b19eabc47a95"
...

  
# color labels 수정 확인
master@master:~$ kubectl get pod jinsunginx --show-labels
NAME         READY   STATUS    RESTARTS   AGE   LABELS
jinsunginx   1/1     Running   0          12m   color=orange,run=jinsunginx
master@master:~$

 

 

labels 필터링으로 찾기

aster@master:~$ kubectl get pod -l run
NAME          READY   STATUS    RESTARTS   AGE
jinsu2nginx   1/1     Running   0          7m15s
jinsunginx    1/1     Running   0          14m
master@master:~$

master@master:~$ kubectl get pod -l run=jinsunginx
NAME         READY   STATUS    RESTARTS   AGE
jinsunginx   1/1     Running   0          15m
master@master:~$

 

 

node selector 이용하여 disktype 구분

master@master:~$ kubectl label node master disktype=ssd
# node/master labeld
master@master:~$ 

master@master:~$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: jinsunginx
  name: jinsunginx
spec:
  containers: 
  - name: jinsunginx
    image: nginx
  nodeSelector:
    disktype: ssd
EOF
master@master:~$

 

 

 

 

 

참고자료

https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/labels/

반응형
반응형

 

 

Pod 구성하는 YAML 파일 생성

# pod 생성하는 YAML 파일 생성
master@master:~$ cat jinsunginx.yaml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: jinsunginx
  name: jinsunginx
spec:
  containers:
  - name: nginx
    image: nginx
master@master:~$

 

 

YAML 파일로 Pod 생성

# YAML 파일로 Pod 생성
master@master:~$ kubectl apply -f jinsunginx.yaml 
pod/jinsunginx created
master@master:~$


# 생성한 Pod 확인
master@master:~$ kubectl get pod jinsunginx -oyaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"labels":{"run":"jinsunginx"},"name":"jinsunginx","namespace":"default"},"spec":{"containers":[{"image":"nginx","name":"nginx"}]}}
  creationTimestamp: "2022-08-07T06:26:05Z"
  labels:
    run: jinsunginx
  name: jinsunginx
  namespace: default
  resourceVersion: "5061"
  selfLink: /api/v1/namespaces/default/pods/jinsunginx
  uid: 40941481-58b6-4684-8cce-7dd2dd84653b
spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: nginx
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-g8wm6
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: master
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: default-token-g8wm6
    secret:
      defaultMode: 420
      secretName: default-token-g8wm6
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2022-08-07T06:26:05Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2022-08-07T06:26:09Z"
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2022-08-07T06:26:09Z"
    status: "True"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2022-08-07T06:26:05Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: docker://101279274be74990989e719696b2853cc3b5da4c382a78f4e738aa9bbb14f4e3
    image: nginx:latest
    imageID: docker-pullable://nginx@sha256:ecc068890de55a75f1a32cc8063e79f90f0b043d70c5fcf28f1713395a4b3d49
    lastState: {}
    name: nginx
    ready: true
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2022-08-07T06:26:09Z"
  hostIP: 192.168.0.201
  phase: Running
  podIP: 10.42.0.6
  podIPs:
  - ip: 10.42.0.6
  qosClass: BestEffort
  startTime: "2022-08-07T06:26:05Z"
master@master:~$

 

 

Kubectl run명령으로 yaml 파일 생성

  • 커맨드는 서비스에 대한 구성을 생성하지만, 이를 kube-apiserver에 전송하는 대신 YAML 형식으로 stdout에 출력한다.
kubectl run redis --image=redis --dry-run=client -o yaml > redis.yaml

cat redis.yaml

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: redis
  name: redis
spec:
  containers:
  - image: redis
    name: redis
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

 

 

즉석 리소스 생성

# 즉시 리소스 생성
master@master:~$ cat << EOF | kubectl apply -f -
> apiVersion: v1
> kind: Pod
> metadata:
>   labels:
>     run: jinsunginx
>   name: jinsunginx
> spec:
>   containers:
>   - name: nginx
>     image: nginx
>     ports:
>     - containerPort: 80
> EOF
pod/jinsunginx created
master@master:~$

# 상태 확인
master@master:~$ kubectl get pod
NAME         READY   STATUS    RESTARTS   AGE
jinsunginx   1/1     Running   0          15s
master@master:~$ kubectl get pod jinsunginx -oyaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"labels":{"run":"jinsunginx"},"name":"jinsunginx","namespace":"default"},"spec":{"containers":[{"image":"nginx","name":"nginx","ports":[{"containerPort":80}]}]}}
  creationTimestamp: "2022-08-07T07:03:01Z"
  labels:
    run: jinsunginx
  name: jinsunginx
  namespace: default
  resourceVersion: "6649"
  selfLink: /api/v1/namespaces/default/pods/jinsunginx
  uid: fd90af8b-8d3d-40fb-bd3c-7ac553728cc5
spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: nginx
    ports:
    - containerPort: 80
      protocol: TCP
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-g8wm6
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: master
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: default-token-g8wm6
    secret:
      defaultMode: 420
      secretName: default-token-g8wm6
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2022-08-07T07:03:01Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2022-08-07T07:03:06Z"
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2022-08-07T07:03:06Z"
    status: "True"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2022-08-07T07:03:01Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: docker://aeab365d5f8ea73911e2218105f0194825748ae244cd377a718e68d78cae7557
    image: nginx:latest
    imageID: docker-pullable://nginx@sha256:ecc068890de55a75f1a32cc8063e79f90f0b043d70c5fcf28f1713395a4b3d49
    lastState: {}
    name: nginx
    ready: true
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2022-08-07T07:03:05Z"
  hostIP: 192.168.0.201
  phase: Running
  podIP: 10.42.0.8
  podIPs:
  - ip: 10.42.0.8
  qosClass: BestEffort
  startTime: "2022-08-07T07:03:01Z"
master@master:~$

 

 

 

 

 

 

 

반응형
반응형

 

초기 구성

# 필요 프로그램 설치
master@master:~$ sudo apt-get update
master@master:~$ sudo apt-get install -y docker.io
master@master:~$ sudo apt-get install -y nfs-common
master@master:~$ sudo apt-get install -y python3-dev
master@master:~$ sudo apt-get install -y python3-pip

# Master Node 필요 설정 및 버전 구성(중요)
master@master:~$ curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="\
    --disable traefik \
    --disable metrics-server \
    --node-name master --docker" \
    INSTALL_K3S_VERSION="v1.17.4+k3s1" sh -s -

# sudo 명령 없이 사용자 권한 설정 구성
master@master:~$ mkdir ~/.kube
master@master:~$ sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
master@master:~$ sudo chown -R $(id -u):$(id -g) ~/.kube
master@master:~$ echo "export KUBECONFIG=~/.kube/config" >> ~/.bashrc
master@master:~$ source ~/.bashrc
master@master:~$ kubectl get node
NAME     STATUS   ROLES    AGE     VERSION
master   Ready    master   2m42s   v1.17.4+k3s1
master@master:~$

 

반응형
반응형

 

Kubernetes 란 무엇인가 ? 

쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위해 만들어진 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 간편한 구성과 자동화를 모두 편리하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 아키텍처를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다.

쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. K8s라는 표기는 "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기이다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다.

 

  • 전통적인 배포 시대

여태까지 대부분 데이터센터나 서버스를 구성할 때 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다. 이에 대한 해결책은 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행하는 것이 있다. 그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았으므로, 물리 서버를 많이 유지하기 위해서 관리하는 조직에 많은 비용이 들었다.

  • 가상화된 배포 시대

그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다.

가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable) 가상 머신으로 구성된 클러스터로 만들 수 있다.

각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다.

  • 컨테이너 개발 시대

컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 쉽게 이식하거나 연동할 수 있다.

 

 

 

 

쿠버네티스가 왜 필요하고 무엇을 할 수 있는가 ?

컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 장애가 있는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?

그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리 할 수 있다. 쿠버네티스는 다음을 제공한다.

 

  • 서비스 관리와 로드 밸런싱

쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.

 

  • 스토리지 관리

 쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다.

 

  • 자동화된 롤아웃과 롤백 

쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.

 

  • 자동화된 빈 패킹(bin packing)

컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.

 

  • 자동화된 복구(self-healing)

쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.

 

  • 시크릿과 구성 관리

쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.

 

 

 

 

 

 

클러스터 아키텍처

Control Plane은 클러스터의 두뇌 역활을 하며 컨테이너 스케쥴링, 서비스 관리, API 요청 처리 등의 작업을 수행한다.

컨트롤 플레인 컴포넌트는 클러스터 내 Master node에서 실행된다.

 

  • kube-apiserer : 컨트롤 플레인의 프론트 엔드 서버로 API 요청을 처리
  • etcd : 어떤 노트가 존재하고 클러스터에 어떤 리소스가 존재하는지 쿠버네티스와 관련된 모든 정보를 저장하는 데이터베이스 역활
  • kube-scheduler : 새로 생성된 Pod를 실행할 노드를 결정
  • kube-controller-manager : 디플로이먼트와 같은 리소스 컨트롤러를 관리
  • cloud-controller-manager : 클라우드 기반 업체와 연동하여 로드 밸런서나 디스크 볼륨과 같은 자원을 관리

 

 

노드 컴포넌트

Worker node는 클러스터 내에서 사용자의 워크로드를 실행합니다.

쿠버네티스 클러스터의 각 Worker node는 다음과 같은 컴포넌트를 실행합니다.

 

  • kubelet : 노드에 예약된 워크로드를 실행하기 위해 컨테이너 런타임을 관리하고 상태를 모니터링한다.
  • kube-proxy : 서로 다른 노드에 있는 파드 간 통신이나 파드와 인터넷 사이의 네트워크 트래픽을 라우팅한다.
  • Container Runtime : 컨테이너를 시작하고 중지하며 컨테이너 간 통신을 처리한다. 일반적으로 Docker가 사용되지만 쿠버네티스는 rkt나 CRI-O와 같은 다른 컨테이너 런타임도 지원합니다.

 

 

 

 

 

 

감사합니다.

 

 

반응형

+ Recent posts