kubernetes 4/17

파드
 - 하나이상의 컨테이너로 구성된 컨테이너의 묶음
 - IP주소는 Pod에 할당되며 Pod 내의 컨테이너는 네트워크 및 저장소를 공유함

하나의 IP 주소를 여러 컨테이너들의 share 해서 사용한다. port로 구분을 하나보군. 그리고 저장 공간을 공통으로 공유한다.

기본적으로 pod 안의 컨테이너들은, 따로 따로 동작을 하지만, 마치 localhost로 연결된 것 처럼 서로 접근을 할 수 있다.

파드 목록 확인
kubectl get pods

파드 상태
 - Pending
 - Running
 - Succeeded
 - Failed
 - Unknown

Initialized
Ready
ContainersReady
PodScheduled
UnSchedulable -> true or false의 이진 값을 갖는다.

sample-pod 만들었는데 걍 값이 true로만 나오는데? 아 ok. k8s 3/17 게시글 확인

레이블
 - Kubernetes 오브젝트에 관리목적의 부가적 정보를 표시할 때 사용하는 것

kubectl get pods --show-labels

kubectl get nodes --show-labels -> 이건 첨해보네

꿀팁)

예를 들면,

kubectl label nodes kube-node1 performance=high

(high performance를 가지고 있는 node에게 label을 달아줄 수 있겠지)

그냥 kubectl get nodes --show-labels 하면 이렇게 보기 흉하게 나오는데

이렇게 kubectl get nodes -L performance하면 깔끔하게 나온다.

 

머신러닝 연산하는 서버에는 이 서버에는 GPU가 뭐가 달려있따 이렇게 레이블 달아줄 수 있겠지.

kubectl label OBJECT OBJECT_NAME LABEL_KEY=LABEL_VALUE


레이블 셀렉터
 - Kubernetes 오브젝트에서 레이블을 식별하고 검색할 수 있도록 하는 연산자

레이블 검색 방법
 - 특정 키가 있는/없는 대상
 - 특정 키와 값이 있는/없는 대상

레이블 셀렉터 검색 방법
 - 일치성 기준 검색
 - 집합성 기준 검색

kubectl get pods --show-labels -l LABEL_EXPRESSION

근데 이상하게 kubectl get nodes --show-labels -l performance는 안된다? kubectl get nodes -L performance만 돼. kubectl get nodes -l performance도 안돼.

어노테이션(annotations)
 - Kubernetes 오브젝트에 비식별 메타데이터 기록

명령어를 사용한 어노테이션 지정
kubectl annotate OBJECT OJECT_NAME ANNOTATION_KEY=ANNOTATION_VALUE


네임스페이스(Namespace)
 - Kubernetes Cluster를 논리적으로 격리

예를 들면, 모회사에서 쿠버네티스 클러스터를 구성해놓고, 논리적으로 격리한 후 격리된 각 네임 스페이스를 자회사에게 할당하는거지.

kubectl get namespaces

네임스페이스 생성 방법
방법1 : kubectl create namespace  NAMESPACE
방법2 : Manifest File 작성

컨테이너 진단
Probe
 - livenessProbe
    - 컨테이너가 실행되었는지 여부 체크
 - readinessProbe
    - 컨테이너 애플리케이션이 서비스를 제공할 수 있는지 여부를 확인하는 프로브
 - startupProbe
    - 컨테이너 실행 후 애플리케이션이 시작되었는지 여부 확인
    - 다른 Probe와 같이 사용되면 starupProbe가 완료될 때 까지 다른 Probe가 동작하지 않음.

Probe 상태
 - Success
 - Failure
 - Unknown

초기화 컨테이너
 - 파드에서 메인 컨테이너가 실행되기 전에 실행되어 파드의 초기화 작업을 수행하는 컨테이너
 - initContainers 하위에 초기화 컨테이너를 정의함 (먼솔임ㅋㅋ)

-> 밑에 그냥 중분류 말한거임 ㅋㅋ

apiVersion: v1
kind: Pod
metadata:
  name: kubernetes-simple-pod
  labels:
    app: kubernetes-simple-pod
spec:
  initContainers:
  - name: init-myservice
    image: arisu1000/simple-container-app:latest
    command: ['sh', '-c', 'sleep 2; echo hello_world01;']
  - name: init-mydb
    image: arisu1000/simple-container-app:latest
    command: ['sh', '-c', 'sleep 2; echo hello_world02;']
  containers:
  - name: kubernetes-simple-pod
    image: arisu1000/simple-container-app:latest
    command: ['sh', '-c', 'echo this app is running! && sleep 3600'] # 여기서 &&는 echo가 반드시 실행된 후에 sleep 3600 실행! 이란 뜻이래

나는 여기서 더 어떻게 확인해? 이게 끝 아냐? 라고 생각했는데
kubectl describe pods kubernetes-simple-pod을 치면, 

이 pod을 만들면서 생긴 history가 싹 나오잖아. 여기서 확인이 가능한거였어.

아예 Init Containers 란이 생김 ㅋㅋ

 

인프라 컨테이너(pause) - 한 pod 에 위치한 여러 컨테이너의 네트워크 역할.

스태틱 파드(Static Pod)
 - API 서버를 통하지 않고 kubelet이 직접 실행하는 파드
 - 스태틱 파드의 경로는 /etc/kubernetes/manifests/ 이며 이 경로에서 파드의 Manifest File 생성하면 스태틱파드가 생성됨

ㄴ> 이건 왜 필요한거야? 아 api server를 위한 api server를 만들 수는 없으니까?

Static Pod는 Control Plane 뿐만 아니라, Node에 있을 수도 있다.

 

api server의 도움을 받지 않고 만들어졌다. 그래서 kubectl edit pod-test2-container-static-kube 이렇게 바꿔도 반영이 안된다. api server로 만든건 반영이 되는데..

 

그리고 portal에서 manifest파일 지우니까, 딜레이 조금 걸린 후에 실제 pod도 삭제가 됐어.

스태틱 파드 실습
(kube-nodeX에서)
cd /etc/kubernetes/manifests/
sudo vim pod-test2.yaml

(kube-control1에서) 새롭게 생성된 파드 목록 확인
kubectl get pods

파드에 CPU, 메모리 할당

limits
  cpu: CORE
  memory: xxM
requests
  cpu: CORE
  memory: xxM

0.1 = 0.1 core 말하는거야. requests : 요청에 대한 자원, limits : 요청에 대한 최대 한계치

1 core = 1000mili core.

즉, 0.1 core = 100 mili core = 10%

500m이 milli core 말하는거임. 1000=1인거임 그니깐. VMware도 그러더만.

파드 환경 변수 적용

근데 좀 이해가 안돼. v1:spec.nodeName은 어디꺼야???

파드의 컨테이너 내에 쉘을 실행하여 진입
kubectl exec -it kubernetes-simple-pod -- /bin/sh

왜 -- 있음? -> 어디까지가 컨테이너 밖에서 실행할거고 어디까지가 컨테이너 안에서 실행할건지 알려주려고.

아, 컨테이너 안에 들어온다음에 env 치니까 컨테이너 환경변수 쫙 나옴

docker에서도 docker -e value1 = value2 하면 저장할 수 있어.

파드 구성 패턴
 - 사이드카 패턴
     애플리케이션 컨테이너의 기능을 확장하거나 보조하는 용도의 컨테이너가 추가된 파드 구성 패턴

 - 앰배서더 패턴
      파드 내에 애플리케이션 컨테이너가 외부와 통신을 하기 위한 프록시 역할을 수행하는 컨테이너를 추가한 파드 구성 패턴

 - 어댑터 패턴
     외부로 노출되는 정보를 표준화 하는 어댑터 컨테이너를 사용하는 파드 구성 패턴

---------
컨트롤러(Controller)
  파드의 동작을 관리하는 오브젝트
 ReplicationController
 ReplicaSet
 Deployment
 DaemonSet
 StatefulSet
 Job
 CronJob


ReplicationController
 - 일정 갯수의 파드 복제본을 유지해주는 컨트롤러
 - 실행 중인 파드가 종료된 경우 새로운 파드의 복제본을 생성하여 정의된 파드 복제본의 갯수로 유지해 줌.
 - 수동 혹은 자동으로 파드 스케일링이 가능함

ReplicationController 생성
vim rc-myapp.yaml
kubectl create -f rc-myapp.yaml

ReplicationController 목록 확인
kubectl get replicationcontrollers

ReplicationController 상세 정보 확인
kubectl describe replicationcontrollers rc-myapp

(위에서 확인한 파드 이름을 지정하여) ReplicationController에 속한 파드 상세 정보 확인
kubectl describe pod POD

보면 Selector랑 Labels로 관리하나바..... (셀렉터가 머였더라???)

ReplicationController가 label 기반으로 pods를 관리하나봐.

 

질문)

-> 올바른 사용 방법이 아니다. 완전히 동일한 pod면 작동될 것. 근데 굳이??

 

한번 pod을 죽여보자. 진짜 살아나나 보게.

 

kubectl get pods --watch. 여기서 새로 만들어진 pod는 AGE보면 알 수 있다. (요거 거의 실시간으로 나옴!!)

 

ReplicationController와 ReplicaSet의 차이?

ReplicaSet에서 Label/Select을 선택하는 방식이 좀 더 추가됨.

기본적인 사용 방식은 동일함.

ReplicaSet
 - 일정 갯수의 파드를 유지시켜줄 수 있는 컨트롤러
 - 실행 중인 파드가 종료된 경우 새로운 파드의 복제본을 생성하여 정의된 파드 복제본의 갯수로 유지해 줌.
 - 수동 혹은 자동으로 파드 스케일링이 가능함

ReplicaSet 생성
vim REPLICASET.yaml
kubectl create -f REPLICASET.yaml

여기서 apps/v1의 apps는 API Group (api version 세부 사항)이라구 해.

selector 하의 matchLabels로 .... 정하는듯?

 

ReplicaSet 목록 확인
kubectl get replicasets

ReplicaSet 상세 정보 확인
kubectl describe replicasets REPLICASET

(위에서 확인한 파드 이름을 지정하여) ReplicaSet에 속한 파드 상세 정보 확인
kubectl describe pod POD

질문)

appVersion이 Replication Controller에서는 v1이었는데, replicaset에서는 apps/v1입니다.

어떤 차이가 있나요?

-> 사용하는 api랑 버전이 다르다.

 

api 종류들 확인하려면, kubectl api-resources 치면 됨.

kubectl api-resources