[PUBLISHER] upload files #36

* PUSH NOTE : 03. Pods - Running Containers in Kubernetes.md

* PUSH ATTACHMENT : k8s-03.jpeg
This commit is contained in:
2023-07-12 10:28:48 +09:00
committed by GitHub
parent 427b9d87d8
commit f8b5ef9e00

View File

@@ -15,6 +15,7 @@ image:
다양한 쿠버네티스 오브젝트 (resources) 를 살펴보는 단원이다. 가장 기본이 되는 Pod 부터 시작한다. 이외의 모든 것들은 pod 를 관리하거나, pod 를 노출하거나, pod 에 의해 사용된다. 다양한 쿠버네티스 오브젝트 (resources) 를 살펴보는 단원이다. 가장 기본이 되는 Pod 부터 시작한다. 이외의 모든 것들은 pod 를 관리하거나, pod 를 노출하거나, pod 에 의해 사용된다.
## 3.1 Introducing Pods ## 3.1 Introducing Pods
---
**Pod**는 컨테이너의 모임이며, 쿠버네티스의 기본적인 building block 이 된다. 하나 기억할 사실은, 하나의 pod 는 하나의 노드 위에 있게 되므로, pod 내부의 모든 컨테이너는 같은 노드에 존재하게 된다. **Pod**는 컨테이너의 모임이며, 쿠버네티스의 기본적인 building block 이 된다. 하나 기억할 사실은, 하나의 pod 는 하나의 노드 위에 있게 되므로, pod 내부의 모든 컨테이너는 같은 노드에 존재하게 된다.
@@ -87,6 +88,7 @@ Pod 내에 여러 컨테이너를 넣는다면 그에 합당한 이유가 있어
기본적으로는 pod 를 분리하는 쪽으로 결정하는 것이 바람직하다. 특별한 이유가 없다면! 기본적으로는 pod 를 분리하는 쪽으로 결정하는 것이 바람직하다. 특별한 이유가 없다면!
## 3.2 YAML/JSON 파일로부터 pod 만들기 ## 3.2 YAML/JSON 파일로부터 pod 만들기
---
보통 pod 를 비롯한 쿠버네티스 리소스를 만들 때는 YAML/JSON 파일을 Kubernetes API 에 POST 해서 만든다. 보통 pod 를 비롯한 쿠버네티스 리소스를 만들 때는 YAML/JSON 파일을 Kubernetes API 에 POST 해서 만든다.
@@ -177,6 +179,7 @@ $ kubectl port-forward <POD_NAME> <LOCAL_PORT>:<POD_PORT>
- 로컬의 포트를 pod 의 포트로 포워딩해준다. - 로컬의 포트를 pod 의 포트로 포워딩해준다.
## 3.3 레이블을 이용한 pod 구성 ## 3.3 레이블을 이용한 pod 구성
---
Pod 의 개수가 많아질수록 관리가 힘들어지고, 한 서비스에 pod 가 여러 개 존재하게 되므로 (복제본) pod 를 묶어서 관리할 방법이 필요하다. 쿠버네티스는 pod 뿐만 아니라 다른 object 들도 **레이블**을 이용해서 관리한다. Pod 의 개수가 많아질수록 관리가 힘들어지고, 한 서비스에 pod 가 여러 개 존재하게 되므로 (복제본) pod 를 묶어서 관리할 방법이 필요하다. 쿠버네티스는 pod 뿐만 아니라 다른 object 들도 **레이블**을 이용해서 관리한다.
@@ -215,6 +218,7 @@ $ kubectl label po <POD_NAME> <LABEL_KEY>=<LABEL_VALUE>
- 해당 key 가 존재하지 않아야 한다. 만약 덮어쓰고 싶다면 `--overwrite` 를 붙여야 한다. - 해당 key 가 존재하지 않아야 한다. 만약 덮어쓰고 싶다면 `--overwrite` 를 붙여야 한다.
## 3.4 Label selector 를 사용하여 pod 목록 출력하기 ## 3.4 Label selector 를 사용하여 pod 목록 출력하기
---
레이블에 따라 검색하는 기능을 제공한다. 레이블에 따라 검색하는 기능을 제공한다.
@@ -247,6 +251,7 @@ $ kubectl get po -l [CONDITION]
이 section 에서는 pod 목록을 가져오는 용도로 레이블을 사용했지만, 여러 개의 pod 를 한꺼번에 삭제할 때도 사용할 수 있는 등 특정 명령을 pod 의 부분집합에 적용할 수 있게 된다. 이 section 에서는 pod 목록을 가져오는 용도로 레이블을 사용했지만, 여러 개의 pod 를 한꺼번에 삭제할 때도 사용할 수 있는 등 특정 명령을 pod 의 부분집합에 적용할 수 있게 된다.
## 3.5 Pod 스케쥴링 제한 ## 3.5 Pod 스케쥴링 제한
---
일반적으로는 worker node 들에 pod 들이 적당히 배치되어 돌아간다. 그리고 밖에서 볼 때는 어떤 pod 가 어느 노드에 있는지는 보통 상관 없다. 하지만 pod 가 특정 하드웨어가 필요한 경우에는 pod 가 어느 노드로 스케쥴링 되어야 하는지 제한할 필요가 있다. (GPU가 필요하다던가...) 일반적으로는 worker node 들에 pod 들이 적당히 배치되어 돌아간다. 그리고 밖에서 볼 때는 어떤 pod 가 어느 노드에 있는지는 보통 상관 없다. 하지만 pod 가 특정 하드웨어가 필요한 경우에는 pod 가 어느 노드로 스케쥴링 되어야 하는지 제한할 필요가 있다. (GPU가 필요하다던가...)
@@ -285,6 +290,7 @@ spec:
개별적인 하나의 노드가 아니라 node label selector 를 이용해 특정 성질을 가진 노드의 집합을 고려하는 것이 쿠버네티스의 사고방식이다. 개별적인 하나의 노드가 아니라 node label selector 를 이용해 특정 성질을 가진 노드의 집합을 고려하는 것이 쿠버네티스의 사고방식이다.
## 3.6 Annotating Pods ## 3.6 Annotating Pods
---
쿠버네티스 리소스들은 레이블 뿐만 아니라 어노테이션도 가질 수 있는데, 얘도 key-value pair 이다. 레이블과 비슷하지만 selector 가 따로 존재하지는 않아서 이를 이용해 리소스를 분류할 수는 없다. 쿠버네티스 리소스들은 레이블 뿐만 아니라 어노테이션도 가질 수 있는데, 얘도 key-value pair 이다. 레이블과 비슷하지만 selector 가 따로 존재하지는 않아서 이를 이용해 리소스를 분류할 수는 없다.
@@ -305,6 +311,7 @@ $ kubectl annotate pod <POD_NAME> <KEY>=<VALUE>
`kubectl describe pod <POD_NAME>` 으로 추가된 어노테이션을 확인할 수 있다. `kubectl describe pod <POD_NAME>` 으로 추가된 어노테이션을 확인할 수 있다.
## 3.7 Namespace 를 이용한 리소스 그룹화 ## 3.7 Namespace 를 이용한 리소스 그룹화
---
`kubectl get pods` 를 했을 때, 매번 레이블을 이용해서 필터링하지 않으면 모든 pod 가 다 목록에 출력된다. 또한 레이블은 한 집합 내에서 부분집합으로 구분하기 위해서 사용했다. 부분집합들은 서로 겹치기도 한다. `kubectl get pods` 를 했을 때, 매번 레이블을 이용해서 필터링하지 않으면 모든 pod 가 다 목록에 출력된다. 또한 레이블은 한 집합 내에서 부분집합으로 구분하기 위해서 사용했다. 부분집합들은 서로 겹치기도 한다.
@@ -371,6 +378,7 @@ Namespace 를 사용하면 object 들을 분리하여 그룹화 한 후, 특정
예를 들어 두 pod 가 다른 namespace 에 있다고 해서 반드시 통신이 불가능한 것은 아니다. 예를 들어 두 pod 가 다른 namespace 에 있다고 해서 반드시 통신이 불가능한 것은 아니다.
## 3.8 Pod 중지 및 삭제 ## 3.8 Pod 중지 및 삭제
---
### 3.8.1 이름으로 삭제 ### 3.8.1 이름으로 삭제