chore: reorganize all image files and linted documents (#80)

* [PUBLISHER] upload files #62 * [PUBLISHER] upload files #63 * [PUBLISHER] upload files #64 * [PUBLISHER] upload files #65 * [PUBLISHER] upload files #66 * [PUBLISHER] upload files #67 * PUSH NOTE : test-document.md * PUSH NOTE : 09. Lp Functions.md * PUSH ATTACHMENT : mt-09.png * PUSH NOTE : 03. Measure Spaces.md * PUSH ATTACHMENT : mt-03.png * PUSH NOTE : 08. Comparison with the Riemann Integral.md * PUSH ATTACHMENT : mt-08.png * PUSH NOTE : 07. Dominated Convergence Theorem.md * PUSH ATTACHMENT : mt-07.png * PUSH NOTE : 06. Convergence Theorems.md * PUSH ATTACHMENT : mt-06.png * PUSH NOTE : 05. Lebesgue Integration.md * PUSH ATTACHMENT : mt-05.png * PUSH NOTE : test-document.md * [PUBLISHER] upload files #68 * [PUBLISHER] upload files #69 * PUSH NOTE : 08. Comparison with the Riemann Integral.md * PUSH ATTACHMENT : mt-08.png * PUSH NOTE : 02. Construction of Measure.md * PUSH ATTACHMENT : mt-02.png * DELETE FILE : _posts/2023-09-09-test-document.md * DELETE FILE : _posts/Mathematics/Measure Theory/2023-09-09-test-document.md * [PUBLISHER] upload files #70 * PUSH NOTE : Rules of Inference with Coq.md * PUSH NOTE : 수학 공부에 대한 고찰.md * PUSH NOTE : 04. Measurable Functions.md * PUSH ATTACHMENT : mt-04.png * PUSH NOTE : 07. Dominated Convergence Theorem.md * PUSH ATTACHMENT : mt-07.png * PUSH NOTE : 08. Comparison with the Riemann Integral.md * PUSH ATTACHMENT : mt-08.png * PUSH NOTE : 05. Lebesgue Integration.md * PUSH ATTACHMENT : mt-05.png * PUSH NOTE : 03. Measure Spaces.md * PUSH ATTACHMENT : mt-03.png * PUSH NOTE : 09. Lp Functions.md * PUSH ATTACHMENT : mt-09.png * PUSH NOTE : 06. Convergence Theorems.md * PUSH ATTACHMENT : mt-06.png * PUSH NOTE : 02. Construction of Measure.md * PUSH ATTACHMENT : mt-02.png * PUSH NOTE : 01. Algebra of Sets and Set Functions.md * PUSH ATTACHMENT : mt-01.png * PUSH NOTE : 블로그 이주 이야기.md * PUSH ATTACHMENT : blog-logo.png * PUSH ATTACHMENT : github-publisher.png * PUSH NOTE : 05. Services - Enabling Clients to Discover and Talk to Pods.md * PUSH ATTACHMENT : k8s-05.jpeg * PUSH NOTE : 18. Extending Kubernetes.md * PUSH ATTACHMENT : k8s-18.jpeg * PUSH NOTE : 11. Understanding Kubernetes Internals.md * PUSH ATTACHMENT : k8s-11.jpeg * PUSH NOTE : 04. Replication and Other Controllers - Deploying Managed Pods.md * PUSH ATTACHMENT : k8s-04.jpeg * PUSH NOTE : 10. StatefulSets - Deploying Replicated Stateful Applications.md * PUSH ATTACHMENT : k8s-10.jpeg * PUSH NOTE : 02. First Steps with Docker and Kubernetes.md * PUSH ATTACHMENT : k8s-02.jpeg * PUSH NOTE : 06. Volumes - Attaching Disk Storage to Containers.md * PUSH ATTACHMENT : k8s-06.jpeg * PUSH NOTE : 12. Securing the Kubernetes API Server.md * PUSH ATTACHMENT : k8s-12.jpeg * PUSH NOTE : 07. ConfigMaps and Secrets - Configuring Applications.md * PUSH ATTACHMENT : k8s-07.jpeg * PUSH NOTE : 13. Securing Cluster Nodes and the Network.md * PUSH ATTACHMENT : k8s-13.jpeg * PUSH NOTE : 09. Deployments - Updating Applications Declaratively.md * PUSH ATTACHMENT : k8s-09.jpeg * PUSH NOTE : 17. Best Practices for Developing Apps.md * PUSH ATTACHMENT : k8s-17.jpeg * PUSH NOTE : 16. Advanced Scheduling.md * PUSH ATTACHMENT : k8s-16.jpeg * PUSH NOTE : 08. Accessing Pod Metadata and Other Resources from Applications.md * PUSH ATTACHMENT : k8s-08.jpeg * PUSH NOTE : 15. Automatic Scaling of Pods and Cluster Nodes.md * PUSH ATTACHMENT : k8s-15.jpeg * PUSH NOTE : 01. Introducing Kubernetes.md * PUSH ATTACHMENT : k8s-01.jpeg * PUSH NOTE : 03. Pods - Running Containers in Kubernetes.md * PUSH ATTACHMENT : k8s-03.jpeg * PUSH NOTE : 14. Managing Pods' Computational Resources.md * PUSH ATTACHMENT : k8s-14.jpeg * [PUBLISHER] upload files #71 * PUSH NOTE : test-document.md * PUSH NOTE : test-document.md * PUSH ATTACHMENT : test-image.png * DELETE FILE : assets/img/posts/test/test-image.png * [PUBLISHER] upload files #72 * PUSH NOTE : test-document.md * PUSH ATTACHMENT : test-image.png * DELETE FILE : assets/img/posts/test/test-image.png * [PUBLISHER] upload files #73 * PUSH NOTE : test-document.md * PUSH ATTACHMENT : test-image.png * chore: remove test files * [PUBLISHER] upload files #74 * PUSH NOTE : 01. Algebra of Sets and Set Functions.md * PUSH ATTACHMENT : mt-01.png * DELETE FILE : assets/img/posts/Mathematics/Measure Theory/mt-01.png * [PUBLISHER] upload files #76 * PUSH NOTE : 01. Algebra of Sets and Set Functions.md * PUSH ATTACHMENT : mt-01.png * [PUBLISHER] upload files #77 * PUSH NOTE : 09. Lp Functions.md * PUSH ATTACHMENT : mt-09.png * PUSH NOTE : 08. Comparison with the Riemann Integral.md * PUSH ATTACHMENT : mt-08.png * PUSH NOTE : 07. Dominated Convergence Theorem.md * PUSH ATTACHMENT : mt-07.png * PUSH NOTE : 06. Convergence Theorems.md * PUSH ATTACHMENT : mt-06.png * PUSH NOTE : 05. Lebesgue Integration.md * PUSH ATTACHMENT : mt-05.png * PUSH NOTE : 04. Measurable Functions.md * PUSH ATTACHMENT : mt-04.png * PUSH NOTE : 03. Measure Spaces.md * PUSH ATTACHMENT : mt-03.png * PUSH NOTE : 01. Algebra of Sets and Set Functions.md * PUSH ATTACHMENT : mt-01.png * chore: remove images * [PUBLISHER] upload files #78 * PUSH NOTE : 09. Lp Functions.md * PUSH ATTACHMENT : mt-09.png * PUSH NOTE : 08. Comparison with the Riemann Integral.md * PUSH ATTACHMENT : mt-08.png * PUSH NOTE : 07. Dominated Convergence Theorem.md * PUSH ATTACHMENT : mt-07.png * PUSH NOTE : 06. Convergence Theorems.md * PUSH ATTACHMENT : mt-06.png * PUSH NOTE : 05. Lebesgue Integration.md * PUSH ATTACHMENT : mt-05.png * PUSH NOTE : 04. Measurable Functions.md * PUSH ATTACHMENT : mt-04.png * PUSH NOTE : 03. Measure Spaces.md * PUSH ATTACHMENT : mt-03.png * PUSH NOTE : 01. Algebra of Sets and Set Functions.md * PUSH ATTACHMENT : mt-01.png * PUSH NOTE : 18. Extending Kubernetes.md * PUSH ATTACHMENT : k8s-18.jpeg * PUSH NOTE : 17. Best Practices for Developing Apps.md * PUSH ATTACHMENT : k8s-17.jpeg * PUSH NOTE : 16. Advanced Scheduling.md * PUSH ATTACHMENT : k8s-16.jpeg * PUSH NOTE : 15. Automatic Scaling of Pods and Cluster Nodes.md * PUSH ATTACHMENT : k8s-15.jpeg * PUSH NOTE : 14. Managing Pods' Computational Resources.md * PUSH ATTACHMENT : k8s-14.jpeg * PUSH NOTE : 13. Securing Cluster Nodes and the Network.md * PUSH ATTACHMENT : k8s-13.jpeg * PUSH NOTE : 12. Securing the Kubernetes API Server.md * PUSH ATTACHMENT : k8s-12.jpeg * PUSH NOTE : 11. Understanding Kubernetes Internals.md * PUSH ATTACHMENT : k8s-11.jpeg * PUSH NOTE : 10. StatefulSets - Deploying Replicated Stateful Applications.md * PUSH ATTACHMENT : k8s-10.jpeg * PUSH NOTE : 09. Deployments - Updating Applications Declaratively.md * PUSH ATTACHMENT : k8s-09.jpeg * PUSH NOTE : 08. Accessing Pod Metadata and Other Resources from Applications.md * PUSH ATTACHMENT : k8s-08.jpeg * PUSH NOTE : 07. ConfigMaps and Secrets - Configuring Applications.md * PUSH ATTACHMENT : k8s-07.jpeg * PUSH NOTE : 06. Volumes - Attaching Disk Storage to Containers.md * PUSH ATTACHMENT : k8s-06.jpeg * PUSH NOTE : 05. Services - Enabling Clients to Discover and Talk to Pods.md * PUSH ATTACHMENT : k8s-05.jpeg * PUSH NOTE : 04. Replication and Other Controllers - Deploying Managed Pods.md * PUSH ATTACHMENT : k8s-04.jpeg * PUSH NOTE : 03. Pods - Running Containers in Kubernetes.md * PUSH ATTACHMENT : k8s-03.jpeg * PUSH NOTE : 02. First Steps with Docker and Kubernetes.md * PUSH ATTACHMENT : k8s-02.jpeg * PUSH NOTE : 01. Introducing Kubernetes.md * PUSH ATTACHMENT : k8s-01.jpeg * [PUBLISHER] upload files #79 * PUSH NOTE : 02. Construction of Measure.md * PUSH ATTACHMENT : mt-02.png
2025-12-06 22:53:51 +00:00 · 2023-09-10 17:38:27 +09:00
parent e5f865ff0c
commit 3c0c6a13ca
54 changed files with 266 additions and 132 deletions
--- a/_posts/Development/Kubernetes/2021-02-28-01-introducing-k8s.md
+++ b/_posts/Development/Kubernetes/2021-02-28-01-introducing-k8s.md
@@ -7,10 +7,12 @@ title: "01. Introducing Kubernetes"
 date: "2021-02-28"
 github_title: "2021-02-28-01-introducing-k8s"
 image:
-  path: /assets/img/posts/k8s-01.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-01.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-01.jpeg](../../../assets/img/posts/k8s-01.jpeg) _Overview of Kubernetes Architecture (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-1)_
+![k8s-01.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-01.jpeg) _Overview of Kubernetes Architecture (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-1)_

 기존에는 소프트웨어가 커다란 덩어리였지만 최근에는 독립적으로 작동하는 작은 **마이크로서비스**(microservice)로 나뉘고 있다. 이들은 독립적으로 동작하기 때문에, 개발하고 배포하거나 스케일링을 따로 해줄 수 있다는 장점이 있으며, 이 장점은 빠르게 변화하는 소프트웨어의 요구사항을 반영하기에 적합하다.

--- a/_posts/Development/Kubernetes/2021-03-07-02-first-steps.md
+++ b/_posts/Development/Kubernetes/2021-03-07-02-first-steps.md
@@ -7,14 +7,17 @@ title: "02. First Steps with Docker and Kubernetes"
 date: "2021-03-07"
 github_title: "2021-03-07-02-first-steps"
 image:
-  path: /assets/img/posts/k8s-02.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-02.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-02.jpeg](../../../assets/img/posts/k8s-02.jpeg) _Running a container image in Kubernetes (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-2)_
+![k8s-02.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-02.jpeg) _Running a container image in Kubernetes (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-2)_

 도커와 쿠버네티스를 사용하여 간단한 애플리케이션을 배포해 보자!

 ## 2.1 컨테이너 이미지 생성, 실행, 공유하기
+
 ---

 ### 2.1.1 도커 설치
@@ -38,8 +41,8 @@ $ docker run <IMAGE>:[TAG] [COMMAND]
 - 우선 해당 이미지의 latest version (`IMAGE:latest`) 가 로컬에 있는지 확인한다. 없으면 Docker Hub 에서 다운받는다.
 - 이미지로부터 컨테이너를 생성하고 `[COMMAND]` 를 실행한다.

-매 번 `docker run` 을 할 때마다 실행할 명령을 입력하는 것은 불편하므로 보통은 Dockerfile 을 사용해서 실행할 명령을 이미지 생성 과정에 포함시킨다. 
-     
+매 번 `docker run` 을 할 때마다 실행할 명령을 입력하는 것은 불편하므로 보통은 Dockerfile 을 사용해서 실행할 명령을 이미지 생성 과정에 포함시킨다.
+
 이미지도 업데이트 될 수 있기 때문에, 이름은 유지한 채 tag 를 업데이트하여 버전을 관리한다. `latest` 태그는 당연히 이미지의 최신 버전을 가리킨다.

 ### 2.1.2 Creating a trivial Node.js app
@@ -137,7 +140,7 @@ $ docker rm <CONTAINER> # 삭제

 컨테이너를 정지하게 되면 그 잔해가 남아있게 되는데, `rm` 을 이용해 삭제해주면 완전히 제거된다.

-정지한 컨테이너는 `docker ps` 로 확인이 불가능하므로 (실행 중인 컨테이너만 보인다), `docker ps -a` 로 확인한다. 
+정지한 컨테이너는 `docker ps` 로 확인이 불가능하므로 (실행 중인 컨테이너만 보인다), `docker ps -a` 로 확인한다.

 ### 2.1.8 이미지 레지스트리에 이미지 push 하기

@@ -155,6 +158,7 @@ $ docker tag <SOURCE_IMAGE:TAG> <TARGET_IMAGE:TAG>
 `docker login` 으로 로그인 한 뒤, `docker push <NAME:TAG>` 으로 이미지를 push 할 수 있다. 당연히 그 반대인 `docker pull` 도 가능하다.

 ## 2.2 쿠버네티스 클러스터 설정
+
 ---

 일단 로컬에서 하려면 Minikube 를 설치하면 된다.
@@ -203,8 +207,8 @@ $ kubectl describe node <NAME>

 `bash-completion` 을 사용하면 편리하다고 한다.

-
 ## 2.3 Kubernetes 에서 앱 실행하기
+
 ---

 ### 2.3.1 Node.js 앱 배포하기
@@ -235,7 +239,7 @@ $ kubectl get pods
 - `kubectl run` 을 실행하면 Kubernetes API 서버에 REST HTTP 요청을 보낸다.
 - Kubernetes API 서버는 요청을 받아 새로운 ReplicationController 오브젝트를 생성한다.
 - ReplicationController 가 새로운 pod 를 생성하게 되고, 이는 Scheduler 에 의해 어떤 worker 노드에 할당된다.
- Kubelet 이 동작하여 Docker 를 실행하게 하고 Docker 가 컨테이너를 실행한다. 
+- Kubelet 이 동작하여 Docker 를 실행하게 하고 Docker 가 컨테이너를 실행한다.

 ### 2.3.2 애플리케이션에 접근하기

@@ -311,4 +315,4 @@ $ kubectl cluster-info | grep dashboard
 ```

 - 대시보드가 실행 중인 주소를 알려줄 것이다.
- Minikube 의 경우 `minikube dashboard`.
+- Minikube 의 경우 `minikube dashboard`.
--- a/_posts/Development/Kubernetes/2021-03-17-03-pods.md
+++ b/_posts/Development/Kubernetes/2021-03-17-03-pods.md
@@ -7,14 +7,17 @@ title: "03. Pods: Running Containers in Kubernetes"
 date: "2021-03-17"
 github_title: "2021-03-17-03-pods"
 image:
-  path: /assets/img/posts/k8s-03.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-03.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-03.jpeg](../../../assets/img/posts/k8s-03.jpeg) _A container shouldn’t run multiple processes. (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-3)_
+![k8s-03.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-03.jpeg) _A container shouldn’t run multiple processes. (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-3)_

 다양한 쿠버네티스 오브젝트 (resources) 를 살펴보는 단원이다. 가장 기본이 되는 Pod 부터 시작한다. 이외의 모든 것들은 pod 를 관리하거나, pod 를 노출하거나, pod 에 의해 사용된다.

 ## 3.1 Introducing Pods
+
 ---

 **Pod**는 컨테이너의 모임이며, 쿠버네티스의 기본적인 building block 이 된다. 하나 기억할 사실은, 하나의 pod 는 하나의 노드 위에 있게 되므로, pod 내부의 모든 컨테이너는 같은 노드에 존재하게 된다.
@@ -35,7 +38,7 @@ image:

 #### Pod 내의 partial isolation

-Pod 를 사용하면 서로 연관된 프로세스를 실행하는 컨테이너들을 함께 실행할 수 있게 되며, 마치 하나의 머신/컨테이너 안에서 실행되는 것처럼 환경을 제공할 수 있게 된다. 
+Pod 를 사용하면 서로 연관된 프로세스를 실행하는 컨테이너들을 함께 실행할 수 있게 되며, 마치 하나의 머신/컨테이너 안에서 실행되는 것처럼 환경을 제공할 수 있게 된다.

 물론 각 컨테이너도 서로 어느 정도 독립적으로 동작하지만, 같은 pod 내의 container 는 같은 namespace 를 가지고 있고, 또 쿠버네티스 *volume* 을 사용해서 컨테이너들 끼리 파일을 공유하도록 설정할 수도 있다.

@@ -88,6 +91,7 @@ Pod 내에 여러 컨테이너를 넣는다면 그에 합당한 이유가 있어
 기본적으로는 pod 를 분리하는 쪽으로 결정하는 것이 바람직하다. 특별한 이유가 없다면!

 ## 3.2 YAML/JSON 파일로부터 pod 만들기
+
 ---

 보통 pod 를 비롯한 쿠버네티스 리소스를 만들 때는 YAML/JSON 파일을 Kubernetes API 에 POST 해서 만든다.
@@ -144,7 +148,6 @@ $ kubectl create -f <YAML_FILE>

 생성 후 잘 돌아가는지 확인하려면 `kubectl get pods` 로 확인하면 된다.

-
 ### 3.2.4 로그 확인하기

 컨테이너 내의 앱은 파일에 로그를 떨구기보다는 보통은 stdout, stderr 로 로그를 내보낸다. 이렇게 하면 다양한 컨테이너들에서 다양한 애플리케이션을 실행할 때 통일된 방법으로 로그를 확인할 수 있다.
@@ -179,6 +182,7 @@ $ kubectl port-forward <POD_NAME> <LOCAL_PORT>:<POD_PORT>
 - 로컬의 포트를 pod 의 포트로 포워딩해준다.

 ## 3.3 레이블을 이용한 pod 구성
+
 ---

 Pod 의 개수가 많아질수록 관리가 힘들어지고, 한 서비스에 pod 가 여러 개 존재하게 되므로 (복제본) pod 를 묶어서 관리할 방법이 필요하다. 쿠버네티스는 pod 뿐만 아니라 다른 object 들도 **레이블**을 이용해서 관리한다.
@@ -218,6 +222,7 @@ $ kubectl label po <POD_NAME> <LABEL_KEY>=<LABEL_VALUE>
 - 해당 key 가 존재하지 않아야 한다. 만약 덮어쓰고 싶다면 `--overwrite` 를 붙여야 한다.

 ## 3.4 Label selector 를 사용하여 pod 목록 출력하기
+
 ---

 레이블에 따라 검색하는 기능을 제공한다.
@@ -242,7 +247,7 @@ $ kubectl get po -l [CONDITION]
  - `'!<KEY>'` 와 같이 `'...'` 로 감싸주어야 shell 이 `!` 를 계산하지 않는다.
 - `<KEY>!=<VALUE>`: 해당 key 를 갖지만 value 가 아닌 pod 출력
 - `<KEY> in (<VALUE_1>, <VALUE_2>, ...)`: key 의 값이 value 목록에 포함되는 pod 를 출력
- `<KEY> notin (<VALUE_1>, <VALUE_2>, ...)`: key 의 값이 value 목록에 포함되지 않는 pod 를 출력 
+- `<KEY> notin (<VALUE_1>, <VALUE_2>, ...)`: key 의 값이 value 목록에 포함되지 않는 pod 를 출력

 ### 3.4.2 Label selector 에서 여러 조건을 이용하기

@@ -251,6 +256,7 @@ $ kubectl get po -l [CONDITION]
 이 section 에서는 pod 목록을 가져오는 용도로 레이블을 사용했지만, 여러 개의 pod 를 한꺼번에 삭제할 때도 사용할 수 있는 등 특정 명령을 pod 의 부분집합에 적용할 수 있게 된다.

 ## 3.5 Pod 스케쥴링 제한
+
 ---

 일반적으로는 worker node 들에 pod 들이 적당히 배치되어 돌아간다. 그리고 밖에서 볼 때는 어떤 pod 가 어느 노드에 있는지는 보통 상관 없다. 하지만 pod 가 특정 하드웨어가 필요한 경우에는 pod 가 어느 노드로 스케쥴링 되어야 하는지 제한할 필요가 있다. (GPU가 필요하다던가...)
@@ -290,6 +296,7 @@ spec:
 개별적인 하나의 노드가 아니라 node label selector 를 이용해 특정 성질을 가진 노드의 집합을 고려하는 것이 쿠버네티스의 사고방식이다.

 ## 3.6 Annotating Pods
+
 ---

 쿠버네티스 리소스들은 레이블 뿐만 아니라 어노테이션도 가질 수 있는데, 얘도 key-value pair 이다. 레이블과 비슷하지만 selector 가 따로 존재하지는 않아서 이를 이용해 리소스를 분류할 수는 없다.
@@ -311,6 +318,7 @@ $ kubectl annotate pod <POD_NAME> <KEY>=<VALUE>
 `kubectl describe pod <POD_NAME>` 으로 추가된 어노테이션을 확인할 수 있다.

 ## 3.7 Namespace 를 이용한 리소스 그룹화
+
 ---

 `kubectl get pods` 를 했을 때, 매번 레이블을 이용해서 필터링하지 않으면 모든 pod 가 다 목록에 출력된다. 또한 레이블은 한 집합 내에서 부분집합으로 구분하기 위해서 사용했다. 부분집합들은 서로 겹치기도 한다.
@@ -327,7 +335,7 @@ Namespace 를 사용하면 많은 컴포넌트를 가진 복잡한 시스템을

 더불어 namespace 에 따라 접근 제한을 할 수 있는데 12~14장에서 더 알아본다.

-거의 대부분의 리소스들이 namespace 로 관리할 수 있지만, 몇 개는 그렇지 않으며 대표적으로 노드의 경우 namespace 에 구애받지 않는다. 
+거의 대부분의 리소스들이 namespace 로 관리할 수 있지만, 몇 개는 그렇지 않으며 대표적으로 노드의 경우 namespace 에 구애받지 않는다.

 (아마 다른 cluster 레벨의 리소스도 구애받지 않을 것 같다)

@@ -378,6 +386,7 @@ Namespace 를 사용하면 object 들을 분리하여 그룹화 한 후, 특정
 예를 들어 두 pod 가 다른 namespace 에 있다고 해서 반드시 통신이 불가능한 것은 아니다.

 ## 3.8 Pod 중지 및 삭제
+
 ---

 ### 3.8.1 이름으로 삭제
@@ -422,19 +431,22 @@ $ kubectl delete all --all

 ### `kubectl apply` 와 `kubectl create` 의 차이점

- Imperative vs Declarative 
+- Imperative vs Declarative
 - https://kubernetes.io/docs/concepts/overview/working-with-objects/object-management/
 - https://stackoverflow.com/questions/47369351/kubectl-apply-vs-kubectl-create

 ### Kubernetes object 와 Kubernetes resource 의 차이점
+
 - https://stackoverflow.com/a/59952807/7788730

 ### Namespace 의 올바른 사용법

 ### JSON vs YAML
+
 - https://stackoverflow.com/questions/1726802/what-is-the-difference-between-yaml-and-json

 ### Label 과 namespace 의 차이
+
 - Label selector 를 이용하면 namespace 처럼 분리가 가능
 - 하지만 namespace 는 label 보다 상위 개념
 - Namespace 를 이용하면 resource quota 를 이용해서 하드웨어 리소스 분배가 가능
@@ -443,12 +455,16 @@ $ kubectl delete all --all
 ### Annotation 의 올바른 사용법

 ### Linux 에 존재하는 namespace 들의 종류
+
 - UTS namespace 란?
-	
+
+
 ### Pod 에 각각 IP 주소가 부여되는 원리
+
 - https://ronaknathani.com/blog/2020/08/how-a-kubernetes-pod-gets-an-ip-address/

 ### MSA vs Microservice 간 통신으로 인한 오버헤드
+
 - MSA 를 사용하면
 	- 책임이 분배되어 프로젝트 관리가 용이하고
 	- 개발하기 편하고 확장이 쉬워짐 (microservice 별로 확장)
--- a/_posts/Development/Kubernetes/2021-03-21-04-replication-and-controllers.md
+++ b/_posts/Development/Kubernetes/2021-03-21-04-replication-and-controllers.md
@@ -7,14 +7,17 @@ title: "04. Replication and Other Controllers: Deploying Managed Pods"
 date: "2021-03-21"
 github_title: "2021-03-21-04-replication-and-controllers"
 image:
-  path: /assets/img/posts/k8s-04.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-04.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-04.jpeg](../../../assets/img/posts/k8s-04.jpeg) _ReplicationController recreating pods. (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-4)_
+![k8s-04.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-04.jpeg) _ReplicationController recreating pods. (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-4)_

 3장에서는 pod 를 직접 관리하는 방법에 대해 살펴봤다. 하지만 실무에서는 pod 의 관리가 자동으로 되길 원한다. 이를 위해 ReplicationController 나 Deployment 를 사용한다.

 ## 4.1 Keeping pods healthy
+
 ---

 Pod 내의 컨테이너가 (오류로 인해) 죽으면, Kubelet 이 자동으로 해당 컨테이너를 재시작한다. 하지만 컨테이너의 프로세스가 종료되지 않았는데 애플리케이션이 동작하지 않는 경우가 있고, (JVM OOM 에러) 애플리케이션이 deadlock 이나 무한 루프에 빠져서 동작하지 않는 경우가 생길 수도 있다. 이런 경우에도 컨테이너가 자동으로 재시작되게 해야한다. 물론 앱이 자체적으로 에러를 감지해서 프로세스를 종료할 수도 있겠지만, 내부적으로 에러를 감지하기 보다는 **컨테이너 밖에서** 컨테이너의 상태를 확인해야 한다.
@@ -31,7 +34,7 @@ Pod 내의 컨테이너가 (오류로 인해) 죽으면, Kubelet 이 자동으
  - 응답 코드가 2xx, 3xx 이면 OK
  - 이외의 에러 코드나 응답이 없으면 실패로 간주하고 컨테이너 재시작
 - **TCP socket probe**: 컨테이너의 정해진 포트에 TCP 연결을 시도해서 실패하면 컨테이너 재시작
- **Exec probe**: 컨테이너 안에서 임의의 명령을 실행하고 exit code 가 0 이 아니면 컨테이너 재시작 
+- **Exec probe**: 컨테이너 안에서 임의의 명령을 실행하고 exit code 가 0 이 아니면 컨테이너 재시작

 ### 4.1.2 HTTP-based liveness probe 만들기

@@ -91,9 +94,10 @@ spec:
 - Liveness probe 는 가벼워야 한다.
  - 자원을 너무 많이 소모해서도 안되고, 지나치게 오래 걸려도 안된다.
 - Liveness probe 구현 시 재시도 횟수를 포함하여 구현할 필요 없다.
-  - `failureThreshold` 옵션을 이용한다. 
+  - `failureThreshold` 옵션을 이용한다.

 ## 4.2 ReplicationControllers
+
 ---

 컨테이너가 죽으면 liveness probe 등을 이용하여 다시 재시작하면 된다. 이 작업은 pod 가 존재하고 있는 노드의 Kubelet 이 해준다. 그런데 만약 노드가 죽으면? Control Plane 이 직접 나서서 죽어버린 pod 를 다시 살려야 한다.
@@ -213,7 +217,7 @@ $ kubectl scale rc <RC_NAME> --replicas=<REPLICAS>
 ```bash
 $ kubectl edit rc <RC_NAME>
 ```
- 
+
 으로 YAML 파일을 직접 수정하여 scaling 을 할 수 있다. 개수만 바꿔주면 나머지는 ReplicationController 가 알아서 한다.

 ### 4.2.7 ReplicationController 삭제하기
@@ -223,6 +227,7 @@ $ kubectl edit rc <RC_NAME>
 Pod 가 관리되지 않은 채로 남아있다고 하더라도, 다시 ReplicationController 를 생성해서 얼마든지 다시 관리할 수 있다.

 ## 4.3 ReplicaSet
+
 ---

 ReplicationControllers will eventually be deprecated!
@@ -290,6 +295,7 @@ selector:
 항상 ReplicationController 대신 ReplicaSet 을 사용해라!

 ## 4.4 DaemonSet 을 이용하여 한 노드에 pod 하나씩 실행하기
+
 ---

 ReplicationController 나 ReplicaSet 을 사용하면 클러스터 내의 임의의 노드에서 실행하게 되는데, 각 노드마다 하나씩 존재해야 하는 앱이 있을 수도 있다. (한 노드가 여유롭다고 몰리면 안된다) 대표적으로 노드의 리소스를 확인하거나 노드의 로그를 확인하고 싶은 경우가 그렇다.
@@ -319,6 +325,7 @@ template:
 ```

 ## 4.5 Running pods that perform a single completable task
+
 ---

 여기서 single completable task 란, 동작을 모두 마치면 종료하는 작업을 말하는 것이다. (기존에는 서버와 같이 계속 실행 중이어야 하는 프로세스를 다뤄왔다. 이 프로세스들은 완료 - 'completed' 의 개념이 없다)
@@ -396,6 +403,7 @@ $ kubectl scale job <JOB_NAME> --replicas <NUM_REPLICAS>
 더불어 `.spec.backoffLimit` 옵션을 사용하면 최대 몇 번까지 작업을 재시도할지 설정할 수 있다. 다만 `activeDeadlineSeconds` 가 더 우선 순위가 높아 시간이 초과되면 재시도 횟수가 남아도 그냥 실패 처리한다.

 ## 4.6 Scheduling Jobs to run periodically or once in the future
+
 ---

 ### 4.6.1 CronJob 만들기
--- a/_posts/Development/Kubernetes/2021-04-07-05-services.md
+++ b/_posts/Development/Kubernetes/2021-04-07-05-services.md
@@ -7,16 +7,19 @@ title: "05. Services: Enabling Clients to Discover and Talk to Pods"
 date: "2021-04-07"
 github_title: "2021-04-07-05-services"
 image:
-  path: /assets/img/posts/k8s-05.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-05.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-05.jpeg](../../../assets/img/posts/k8s-05.jpeg) _Using `kubectl exec` to test out a connection to the service by running curl in one of the pods. (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-5)_
+![k8s-05.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-05.jpeg) _Using `kubectl exec` to test out a connection to the service by running curl in one of the pods. (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-5)_

 많은 앱들이 request (요청) 을 받아 서비스를 제공하는 형태인데, 이런 요청을 보내려면 IP 주소를 알아야 한다. 한편 Kubernetes 를 사용하게 되면 pod 의 IP 주소를 알아야 하는데, Kubernetes 의 pod 들은 굉장히 동적이므로 이들의 IP 주소를 알아낼 방법이 필요하다.

 Pod 들은 스케쥴링 되고 스케일링 되기 때문에 IP 주소가 자주 바뀔 수 있으며, pod 가 시작된 후 IP 주소가 할당될 뿐만 아니라, 하나의 서비스를 위해 pod 를 여러 개 사용하는 경우 하나의 IP 를 사용하여 여러 개의 pod 에 접근할 방법이 필요하다. (쿠버네티스를 사용하지 않으면 고정 IP 등을 사용하거나 따로 설정된 주소로 요청이 가도록 했을 것이다)

 ## 5.1 Services 소개
+
 ---

 Service 를 이용하면 같은 일을 하는 여러 개의 pod 에 하나의 entrypoint 를 제공할 수 있다.
@@ -143,6 +146,7 @@ FQDN 은 대략 이런 모양이다.
 정확히는, `ping` 명령어는 ICMP 위에서 동작한다. 그런데 service 의 클러스터 내부에서 특정 포트만 사용하기 때문에 ICMP request 에 응답하지 않으므로 `ping` 이 불가능하다.

 ## 5.2 클러스터 외부의 service 에 접속하기
+
 ---

 ### 5.2.1 Service endpoints
@@ -170,6 +174,7 @@ Label selector 를 지정하면 endpoints 가 자동으로 관리되고, label s
 `ExternalName` service 들은 DNS 레벨에서 구현되어 있어서 `CNAME` record 가 생성된다. 이 service 에 접속을 시도하는 client 들은 외부 서비스에 직접 접속하며, service 에는 IP 가 할당 되지 않는다.

 ## 5.3 Service 를 외부에 공개하기
+
 ---

 프론트엔드의 경우 외부로 공개할 필요가 있다. 공개하는 방법에는 세 가지 방법이 있다.
@@ -223,6 +228,7 @@ Service 타입을 `LoadBalancer` 로 설정하면 된다. 다만 cloud infrastru
 `NodePort` service 를 통해 외부에서 접근하게 되면 SNAT 로 인해 source IP 가 변경된다. (내부에서는 무관) 그런데 만약 애플리케이션이 source IP 를 필요로 한다면 문제가 될 수도 있다.

 ## 5.4 Ingress resource
+
 ---

 ### Ingress 가 필요한 이유
@@ -233,7 +239,7 @@ Service 타입을 `LoadBalancer` 로 설정하면 된다. 다만 cloud infrastru

 (IP 주소 하나 쓰는 것만으로는 조금 부족해 보이는데 어떤 기능들이 있는지 확인해 봐야겠다.)

-더불어 Ingress 가 동작하려면 Ingress controller 가 동작하고 있어야 한다. 
+더불어 Ingress 가 동작하려면 Ingress controller 가 동작하고 있어야 한다.

 ### 5.4.1 Ingress 리소스 생성

@@ -329,6 +335,7 @@ spec:
 ```

 ## 5.5 연결을 받을 준비가 되었을 때 신호 보내기
+
 ---

 Service 나 Ingress 를 사용하면 pod 가 생성되자마자 요청이 전달될 수 있다. (label 만 검사하므로) 한편 startup 이 오래걸리는 애플리케이션의 경우 아직 pod 는 준비가 안되었는데 요청을 받게 되어 요청을 정상적으로 처리 못하게 될 수 있다.
@@ -350,7 +357,7 @@ Readiness probe 는 주기적으로 실행되며, pod 가 client request 를 받
 #### Understanding the operation of readiness probes

 - 첫 readiness probe 를 실행하기 전 얼만큼 기다릴지 미리 설정할 수 있다. 그 이후에는 주기적으로 실행한다.
- Ready 상태가 아니면 service 의 endpoints 에서 제거되고, 준비가 되면 추가된다. 
+- Ready 상태가 아니면 service 의 endpoints 에서 제거되고, 준비가 되면 추가된다.
 - Liveness probe 는 실패하면 컨테이너를 재시작하지만, readiness probe 는 그렇지 않다.

 Pod 이 죽을 때 어떤 방식으로 endpoints 를 업데이트 하는지? -> 이게 아니고 readiness probe 가 실패해서 endpoints 가 업데이트 되는 듯 하다. + 삭제시 쿠버네티스가 알아서 업데이트 해준다.
@@ -374,6 +381,7 @@ ReplicationController 의 pod template 을 수정하면 현재 존재하는 pod
 Shutdown 이 시작되었음을 감지하고 readiness probe 가 실패하도록 로직을 짤 필요는 없다. Pod 가 삭제되면 쿠버네티스가 자동으로 service endpoints 에서 제거한다.

 ## 5.6 Headless service for discovering individual pods
+
 ---

 Client 가 모든 pod 에 접근해야 한다면? (어떤 경우에 이러한가? - 아래 Discussion 참고)
@@ -401,6 +409,7 @@ $ kubectl run <POD_NAME> --image=<IMAGE_NAME> --generator=run-pod/v1
 Service 에서 `publishNotReadyAddresses=True` 로 설정하면 된다.

 ## 5.7 Troubleshooting
+
 ---

 순서대로 해보면 좋을 것이다!
@@ -410,7 +419,7 @@ Service 에서 `publishNotReadyAddresses=True` 로 설정하면 된다.
 - Readiness probe 를 설정했다면 성공하는지 꼭 확인해야 한다. 그렇지 않으면 pod 가 service 의 endpoints 에 등록되지 않는다.
 - Pod 가 service 의 endpoints 에 등록되었는지 확인하려면 `kubectl get endpoints`.
 - FQDN 으로 접속이 안되면, cluster IP 를 사용해서 되는지 확인해본다.
- Service 의 타겟 포트가 아니고 expose 한 포트로 접속하고 있는지 확인한다. 
+- Service 의 타겟 포트가 아니고 expose 한 포트로 접속하고 있는지 확인한다.
 - Pod IP, 포트로 직접 접속하여 요청을 받는지 확인한다.
 - 마지막으로, 앱이 localhost 에 바인딩 하지 않았는지 확인한다.

@@ -456,6 +465,7 @@ Service 에서 `publishNotReadyAddresses=True` 로 설정하면 된다.
 - `dig` 명령어로 DNS record 조회 가능하다.

 #### 대표적인 records
+
 - A record: 도메인에 IP 를 할당한다.
 - CNAME record: Canonical NAME record 으로, 특정 도메인을 다른 도메인 이름으로 매핑한다.

--- a/_posts/Development/Kubernetes/2021-04-07-06-volumes.md
+++ b/_posts/Development/Kubernetes/2021-04-07-06-volumes.md
@@ -7,14 +7,17 @@ title: "06. Volumes: Attaching Disk Storage to Containers"
 date: "2021-04-07"
 github_title: "2021-04-07-06-volumes"
 image:
-  path: /assets/img/posts/k8s-06.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-06.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-06.jpeg](../../../assets/img/posts/k8s-06.jpeg) _The complete picture of dynamic provisioning of PersistentVolumes. (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-6)_
+![k8s-06.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-06.jpeg) _The complete picture of dynamic provisioning of PersistentVolumes. (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-6)_

 컨테이너가 재시작되면 기존 작업 내역이 모두 사라지게 될 수 있으므로, 컨테이너의 작업 내역을 저장하고 같은 pod 내의 다른 컨테이너가 함께 사용하는 저장 공간이다.

 ## 6.1 Introducing volumes
+
 ---

 Pod 의 한 구성 부분으로 pod spec 에 정의되어 있다. 또 standalone Kubernetes object 가 아니라서 독립적으로 생성되거나 삭제될 수 없다.
@@ -38,6 +41,7 @@ Pod 내의 모든 컨테이너로부터 접근이 가능하지만, 그렇게 하
 - `persistentVolumeClaim`: pre- or dynamically provisioned persistent storage

 ## 6.2 Volume 을 이용한 컨테이너간 데이터 공유
+
 ---

 ### 6.2.1 `emptyDir` volume
@@ -134,6 +138,7 @@ Docker Hub 에서 `git sync` 를 검색하면 많은 이미지들이 나올 것
 (어쩐지, 위 예시 코드 작동 안하더라.)

 ## 6.3 노드의 파일 시스템에 접근하기
+
 ---

 보통 pod 들은 자신이 어떤 노드 위에서 돌아가고 있는지 알 필요가 없기 때문에 노드의 파일 시스템에 접근할 일이 없다. 하지만 시스템 레벨의 pod 들은 (DaemonSet 이라던가) 노드의 파일을 읽어야 하는 경우가 생길 수도 있다. 이런 경우에는 `hostPath` 볼륨을 사용한다.
@@ -153,6 +158,7 @@ Docker Hub 에서 `git sync` 를 검색하면 많은 이미지들이 나올 것
 Single-node 클러스터에서는 `hostPath` volume 을 persistent storage 로 사용할 수 있다. (Minikube) 아무튼 multi-node 클러스터에서는 여러 pod 들 간에 데이터를 공유하거나 persistent storage 로 사용해서는 안된다.

 ## 6.4 Persistent storage
+
 ---

 Pod 들 간에 데이터를 공유해야 한다면, 위에서 언급한 volume type 들은 사용할 수 없다. 클러스터 내의 임의의 노드에서 접근이 가능해야하기 때문에 NAS (network attached storage) 급의 저장장치가 필요하다.
@@ -170,8 +176,8 @@ GCE Persistent Disk 를 생성하고, 이를 mount 한 pod 에서 DB 에 뭔가

 굉장히 다양한 종류의 volume type 을 지원하긴 하는데, 이걸 모두 알 필요는 당연히 없다. 또한 infrastructure 와 관련된 저장소 타입에 대한 정보를 개발자가 알아야할 이유도 없다. Kubernetes 는 이런 정보를 추상화시키는 것이 목적이다. 특정 저장소 정보를 YAML 파일에 기록하게 되면 해당 클러스터의 하드웨어 인프라와 지나치게 연결되어, 다른 클러스터에서 돌아가지 않게 된다. 위에서 제시한 persistent volume 들은 하나의 방법이긴 하지만 최선은 아니다.

-
 ## 6.5 스토리지 기술과 pod 를 분리하기
+
 ---

 개발자는 물리적 저장소에 대한 정보를 몰라야 한다! 그것은 클러스터 관리자가 할 일이다.
@@ -282,6 +288,7 @@ Pod 과 PVC 를 지우고 `kubectl get pv` 를 해보면 `Released` 상태로
 다른 reclaim policy 로는 `Recycle`, `Delete` 가 있다. `Recycle` 은 지우고 새로 만들어서 다른 PVC 가 사용할 수 있도록 한다. `Delete` 는 그냥 지워버린다.

 ## 6.6 Dynamic provisioning of PersistentVolumes
+
 ---

 위에서 살펴본 방식대로 PVC 를 사용하는 것도 편하지만, 여전히 클러스터 관리자가 PV 를 생성해야한다는 점에서 불편하다. 쿠버네티스는 PV 의 dynamic provisioning 을 제공하여 스토리지를 자동으로 만들어준다.
--- a/_posts/Development/Kubernetes/2021-04-18-07-configmaps-and-secrets.md
+++ b/_posts/Development/Kubernetes/2021-04-18-07-configmaps-and-secrets.md
@@ -7,19 +7,22 @@ title: "07. ConfigMaps and Secrets: Configuring Applications"
 date: "2021-04-18"
 github_title: "2021-04-18-07-configmaps-and-secrets"
 image:
-  path: /assets/img/posts/k8s-07.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-07.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-07.jpeg](../../../assets/img/posts/k8s-07.jpeg) _Combining a ConfigMap and a Secret to run your fortune-https pod (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-7)_
+![k8s-07.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-07.jpeg) _Combining a ConfigMap and a Secret to run your fortune-https pod (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-7)_

 거의 대부분의 앱은 설정(configuration)이 필요하다. 개발 서버, 배포 서버의 설정 사항 (접속하려는 DB 서버 주소 등)이 다를 수도 있고, 클라우드 등에 접속하기 위한 access key 가 필요하거나, 데이터를 암호화하는 encryption key 도 설정해야하는 경우가 있다. 이러한 경우에 해당 값들을 도커 이미지 자체에 넣어버리면 보안 상 취약하고, 또 설정 사항을 변경하는 경우 이미지를 다시 빌드해야하는 등 불편함이 따른다.

 이번 장에서는 Kubernetes 에서 돌아가는 애플리케이션에 설정 사항을 넘겨주는 방법을 알아본다.

 ## 7.1 컨테이너화 된 애플리케이션 설정하기
+
 ---

-보통 애플리케이션의 설정 사항을 관리할 때에는 configuration file 이 존재하게 된다. (`.properties`, `.env` 등) 
+보통 애플리케이션의 설정 사항을 관리할 때에는 configuration file 이 존재하게 된다. (`.properties`, `.env` 등)

 그런데 Docker 를 사용하면, config file 을 컨테이너로 옮기는 명령이 Dockerfile 에 필요하게 되고, config file 을 수정하면 이미지를 다시 빌드해야하기 때문에 보통은 컨테이너에 환경 변수(environment variables)를 전달하는 방식으로 사용한다. 그리고 애플리케이션은 환경 변수를 조회하여 사용할 수 있다.

@@ -29,8 +32,9 @@ image:
 - 컨테이너에 command line argument 전달하기
 - 컨테이너마다 환경 변수 설정하기
 - Volume 을 이용해서 config file mount 하기
-  
+
 ## 7.2 컨테이너에 command line argument 전달하기
+
 ---

 보통은 컨테이너 이미지에 정의된 기본 명령으로 이미지를 실행하지만, Kubernetes 에서는 해당 명령을 override 하여 다른 명령을 실행하도록 할 수 있다. 그래서 실행할 때 추가로 argument 를 전달할 수 있게 된다.
@@ -50,17 +54,17 @@ Dockerfile 에서 다음 명령을 사용할 수 있다.
 > - `CMD ["executable","param1","param2"]` (*exec* form, this is the preferred form)
 > - `CMD ["param1","param2"]` (as *default parameters to ENTRYPOINT*)
 > - `CMD command param1 param2` (*shell* form)
->
+> 
 > Dockerfile 에는 하나의 `CMD` 만 존재할 수 있으며, **The main purpose of a CMD is to provide defaults for an executing container.** 라고 한다.
 > *provide default* 라고 했기 때문에 이는 overriding 이 가능하다는 것이다.
->
+> 
 > `ENTRYPOINT` 를 사용하면 컨테이너가 실행될 때 `ENTRYPOINT` 에서 지정한 명령을 수행하고, `CMD` 도 마찬가지지만 `CMD` 의 경우 컨테이너 실행시 인자값을 주면 Dockerfile 의 `CMD` 를 override 하여 실행한다.
->
+> 
 > Reference 에서도 이 둘의 사용법을 설명해줬다.
 > 
 > Both `CMD` and `ENTRYPOINT` instructions define what command gets executed when running a container. There are few rules that describe their co-operation.
 > - Dockerfile should specify at least one of `CMD` or `ENTRYPOINT` commands.
-> - `ENTRYPOINT` should be defined when using the container as an executable. 
+> - `ENTRYPOINT` should be defined when using the container as an executable.
 > - `CMD` should be used as a way of defining default arguments for an `ENTRYPOINT` command or for executing an ad-hoc command in a container.
 > - `CMD` will be overridden when running the container with alternative arguments.

@@ -107,6 +111,7 @@ spec:
 `command`, `args` 필드는 컨테이너가 시작되면 수정할 수 없다.

 ## 7.3 컨테이너 환경 변수 설정하기
+
 ---

 Pod 레벨에서 환경 변수를 설정하고 컨테이너가 이를 상속하게 하는 옵션은 존재하지 않는다.
@@ -146,6 +151,7 @@ env:
 만약 pod 설정을 재사용하고 싶다면 config 와 pod 설정을 분리해야 하므로, 쿠버네티스에서는 ConfigMap 리소스를 제공한다.

 ## 7.4 ConfigMap 으로 설정 분리하기
+
 ---

 앱 설정 사항을 만들 때 가장 많이 고려하는 부분은 자주 바뀌는 설정을 코드와 분리하는 것이다. (그래서 config file 도 만들고, 환경 변수도 쓰고...)
@@ -310,6 +316,7 @@ ConfigMap 을 업데이트하는데 앱이 만약 설정이 변경된 것을 rel
 (??? atomic 하게 된다고 했던 것 같은데...)

 ## 7.5 Secrets for sensitive data
+
 ---

 Credential 의 경우 안전하게 전달되어야 한다.
@@ -386,7 +393,6 @@ Most resource types require a name that can be used as a DNS subdomain name as d
 - start with an alphanumeric character
 - end with an alphanumeric character

-
 ### Resolution of key collisions when creating ConfigMaps?

 - 그냥 애초에 생성이 안 되는 듯 하다.
@@ -423,7 +429,7 @@ data:

 When a ConfigMap already being consumed in a volume is updated, *projected keys are eventually updated as well*. **Kubelet is checking whether the mounted ConfigMap is fresh on every periodic sync**.

-However, it is using its *local ttl-based cache* for getting the current value of the ConfigMap. As a result, the total delay [from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod] can be as long as kubelet sync period (1 minute by default) + ttl of ConfigMaps cache (1 minute by default) in kubelet. 
+However, it is using its *local ttl-based cache* for getting the current value of the ConfigMap. As a result, the total delay [from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod] can be as long as kubelet sync period (1 minute by default) + ttl of ConfigMaps cache (1 minute by default) in kubelet.

 You can trigger an immediate refresh by updating one of the pod's annotations.

--- a/_posts/Development/Kubernetes/2021-04-18-08-accessing-pod-metadata.md
+++ b/_posts/Development/Kubernetes/2021-04-18-08-accessing-pod-metadata.md
@@ -7,10 +7,12 @@ title: "08. Accessing Pod Metadata and Other Resources from Applications"
 date: "2021-04-18"
 github_title: "2021-04-18-08-accessing-pod-metadata"
 image:
-  path: /assets/img/posts/k8s-08.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-08.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-08.jpeg](../../../assets/img/posts/k8s-08.jpeg) _Using the files from the default-token Secret to talk to the API server (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-8)_
+![k8s-08.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-08.jpeg) _Using the files from the default-token Secret to talk to the API server (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-8)_

 ### 주요 내용

@@ -18,6 +20,7 @@ image:
 - 컨테이너 안의 앱이 Kubernetes API 와 통신하고 클러스터의 리소스를 생성/수정하는 방법

 ## 8.1 Passing metadata through the Downward API
+
 ---

 앱의 config data 는 pod 생성 전에 결정되기 때문에 환경 변수나 configMap, secret volume 을 이용해 전달할 수 있었다.
@@ -173,7 +176,7 @@ total 24
 -rw-r--r--    1 root     root             7 Apr 17 06:31 podNamespace
 ```

-> `-L` (`--dereference`) 옵션: when  showing  file information for a symbolic link, show information for the file the link references rather than for the link itself
+> `-L` (`--dereference`) 옵션: when showing file information for a symbolic link, show information for the file the link references rather than for the link itself

 #### label 과 annotation 은 volume 으로만 expose 가능한 이유

@@ -192,9 +195,10 @@ total 24
 Downward API 를 사용하는 것은 간단하다. Shell script 로 환경 변수를 설정하는 등의 수고로움을 덜어줄 것며, 애플리케이션이 Kubernetes 에 의존하지 않게 할 수 있다. 만약 환경 변수 값을 이용해서 동작하는 앱이라면 Downward API 가 유용할 것이다.

 ## 8.2 Talking to the Kubernetes API server
+
 ---

-Downward API 도 다양한 정보를 제공하지만 이로는 부족할 수 있다. (다른 pod/클러스터의 정보가 필요하거나) 그렇다면 Kubernetes API server 와 직접 통신하여 원하는 값을 얻어야 한다. 
+Downward API 도 다양한 정보를 제공하지만 이로는 부족할 수 있다. (다른 pod/클러스터의 정보가 필요하거나) 그렇다면 Kubernetes API server 와 직접 통신하여 원하는 값을 얻어야 한다.

 ### 8.2.1 Exploring the Kubernetes REST API

@@ -349,7 +353,7 @@ KUBERNETES_SERVICE_PORT_HTTPS=443

 > SRV record: specification of data in the DNS defining the location of servers for specified services. 여기서 location 이라 함은 hostname 과 port number 정도로 생각해도 괜찮을 것 같다.

-한 번 `https://kubernetes` 로 요청을 보내보면 인증서가 없어서 실패한다. 
+한 번 `https://kubernetes` 로 요청을 보내보면 인증서가 없어서 실패한다.

 ```
 root@curl:/# curl https://kubernetes
@@ -430,11 +434,13 @@ $ curl -H "Authorization: Bearer $TOKEN" https://kubernetes
 ```

 > Role-based access control ([RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)) 이 실행되고 있는 클러스터에서는 위 `curl` 에서 에러가 난다. 일단 테스트를 위해서 임시적으로
+> 
 > ```bash
 > kubectl create clusterrolebinding permissive-binding \
 > --clusterrole=cluster-admin \
 > --group=system:serviceaccounts
 > ```
+> 
 > 를 입력하여 모든 serviceaccounts 에 admin 권한을 줄 수 있다 ㅋㅋㅋ;

 #### 현재 pod 의 namespace 가져오기
--- a/_posts/Development/Kubernetes/2021-04-30-09-deployments.md
+++ b/_posts/Development/Kubernetes/2021-04-30-09-deployments.md
@@ -7,10 +7,12 @@ title: "09. Deployments: Updating Applications Declaratively"
 date: "2021-04-30"
 github_title: "2021-04-30-09-deployments"
 image:
-  path: /assets/img/posts/k8s-09.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-09.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-09.jpeg](../../../assets/img/posts/k8s-09.jpeg) _Rolling update of Deployments (출처: livebook.manning.com/book/kubernetes-in-action/chapter-9)_
+![k8s-09.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-09.jpeg) _Rolling update of Deployments (출처: livebook.manning.com/book/kubernetes-in-action/chapter-9)_

 ### 주요 내용

@@ -19,6 +21,7 @@ image:
  - 롤백하는 방법

 ## 9.1 Updating applications running in pods
+
 ---

 만약 서비스/앱을 업데이트하고 싶다면 2가지 방법이 있다.
@@ -61,6 +64,7 @@ Rolling update 방식에서는 pod 를 조금씩 교체한다.
 롤링 업데이트는 수동으로 하면 실수할 확률이 매우 높으므로, 자동화하는 것이 좋다.

 ## 9.2 Performing an automatic rolling update with a ReplicationController
+
 ---

 > 아래에 소개되는 방법은 이제는 사용하지 않는 방법이다!
@@ -114,7 +118,7 @@ ReplicationController `kubia-v1` 을 `kubia-v2` 로 업데이트하고, 이미

 #### 동작 과정

-`kubectl` 은 `kubia-v1` ReplicationController 의 pod template 을 그대로 가져와서 image 만 바꿔치기한 후 `kubia-v2` 를 만든다. 
+`kubectl` 은 `kubia-v1` ReplicationController 의 pod template 을 그대로 가져와서 image 만 바꿔치기한 후 `kubia-v2` 를 만든다.

 또한 label 에 `deployment=...` 이 추가된 것을 확인할 수 있다. 만약 label 이 변경되지 않는다면 같은 label selector 를 갖는 ReplicationController 가 2개 존재하게 될 것이므로 문제가 생긴다. (새로 생긴 rc 가 동작할 필요가 없어진다)

@@ -130,7 +134,7 @@ Label 변경이 끝나면 본격적으로 scaling 이 시작되고, pod 는 하

 - 사용자가 생성한 object 들을 Kubernetes 가 직접 수정하는 것이 좋지 않다.
  - 위에서 `deployment=...` label 이 추가되는 것처럼
- `kubectl` *client* 가 모든 작업을 수행한다. 
+- `kubectl` *client* 가 모든 작업을 수행한다.
  - `kubectl rolling-update ... --v 6` 을 하면 로그를 볼 수 있다.
  - 로그를 보면 `kubectl` 이 API 서버에 보내는 요청을 하나씩 확인할 수 있다.
  - Client 가 작업을 수행하게 되면 중간에 네트워크 연결이 유실되면 업데이트가 멈춰버린다.
@@ -141,6 +145,7 @@ Label 변경이 끝나면 본격적으로 scaling 이 시작되고, pod 는 하
 > `--v 6` 하면 로깅 레벨을 높여서 `kubectl` 이 API 서버에 보내는 요청을 볼 수 있다.

 ## 9.3 Using Deployments for updating apps declaratively
+
 ---

 > Declarative 와 imperative 가 서로 상반되는 개념인듯 하다.
@@ -189,13 +194,14 @@ deployment "kubia" successfully rolled out

 #### 생성된 pod, ReplicaSet 확인

-`kubectl get po` 로 만들어진 pod 들을 확인할 수 있고, `kubectl get rs` 를 해보면 ReplicaSet 이 생겼다는 것을 알 수 있다. 
+`kubectl get po` 로 만들어진 pod 들을 확인할 수 있고, `kubectl get rs` 를 해보면 ReplicaSet 이 생겼다는 것을 알 수 있다.

 그리고 ReplicaSet 의 이름에는 pod template 의 hash 값이 들어가 있는데, 이렇게 하는 이유는 Deployment 가 직접 pod 를 제어하지 않고 ReplicaSet 이 하기 때문이다. Deployment 는 ReplicaSet 을 여러 개 만들기도 하는데, 이때 이미 존재하는 ReplicaSet 을 추가로 만들지 않고 그대로 사용할 수 있게 된다. (pod template 이 같다면 hash 값이 일치하므로 재사용이 가능하다.)

-> 앞에서 `kubectl rolling-update` 를 사용할 때는 ReplicationController 에 label 이 추가되는 부분이 있었는데, 이는 같은 label selector 를 사용하는 여러 개의 ReplicationController 생성을 막기 위한 것이었다. 
->
-> ReplicaSet 도 이 문제에서 자유롭지는 못할 것 같아서 확인해보니, label selector 에 `pod-template-hash` 가 있는 것을 확인할 수 있었다. 
+> 앞에서 `kubectl rolling-update` 를 사용할 때는 ReplicationController 에 label 이 추가되는 부분이 있었는데, 이는 같은 label selector 를 사용하는 여러 개의 ReplicationController 생성을 막기 위한 것이었다.
+> 
+> ReplicaSet 도 이 문제에서 자유롭지는 못할 것 같아서 확인해보니, label selector 에 `pod-template-hash` 가 있는 것을 확인할 수 있었다.
+> 
 > ```
 > $ kubectl get po --show-labels                          
 > NAME                     READY   STATUS    RESTARTS   AGE   LABELS
@@ -203,6 +209,7 @@ deployment "kubia" successfully rolled out
 > kubia-74967b5695-djsfb   1/1     Running   0          17s   app=kubia,pod-template-hash=74967b5695
 > kubia-74967b5695-h7d2b   1/1     Running   0          17s   app=kubia,pod-template-hash=74967b5695
 > ```
+> 
 > 실제로 pod template hash 값을 사용하나보다.

 #### Service 생성
@@ -301,29 +308,32 @@ $ kubectl rollout undo deployment kubia --to-revision=1

 위에서 Deployment 생성시 `--record` 명령을 사용했기 때문에 `CHANGE-CAUSE` 에 revision history 가 상세하게 남게 된다.

-> `--record` 를 사용하지 않고 Deployment 를 생성하면 history 에서 `CHANGE-CAUSE` 열이 `<none>` 으로 표시된다.
+> `--record` 를 사용하지 않고 Deployment 를 생성하면 history 에서 `CHANGE-CAUSE` 열이 `<none> ` 으로 표시된다.
 > 
 > ```
 > $ kubectl rollout history deployment kubia
 > deployment.apps/kubia 
 > REVISION  CHANGE-CAUSE
-> 1        \ <none\>
-> 2         \<none\>
+> 1        \ <none\> 
+> 2         \<none\> 
 > ```
 > 
-> 또한, ReplicaSet 을 강제로 삭제하게 되면 그와 관련된 revision 도 함께 삭제된다. 
+> 또한, ReplicaSet 을 강제로 삭제하게 되면 그와 관련된 revision 도 함께 삭제된다.
+> 
 > ```
 > $ kubectl rollout history deployment kubia
 > deployment.apps/kubia 
 > REVISION  CHANGE-CAUSE
-> 2         \<none\>
+> 2         \<none\> 
 > ```
->
+> 
 > 그러므로 `kubectl rollout undo` 도 사용이 불가능하다.
+> 
 > ```
 > $ kubectl rollout undo deployment kubia   
 > error: no rollout history found for deployment "kubia"
 > ```
+> 
 > 그냥 궁금해서 테스트했는데 뒤에 나와있다. ㅋㅋ

 그렇다면 revision 이 생길 때마다 ReplicaSet 이 남아있게 되므로 이는 작업할 때 매우 불편할 것이다. 그래서 `revisionHistoryLimit` 옵션을 Deployment 에 주게 되면 해당 개수 만큼만 revision history 가 남는다.
@@ -451,11 +461,11 @@ kubia-bcf9bb974-k7cxf    1/1     Running   0          7m14s
 당연히, available 상태가 되지 않았으므로 rollout 은 더 이상 진행될 수 없으며 (`maxUnavailable`) `READY` 상태가 아닌 pod 들은 Service Endpoints 에서 제거되기 때문에 과거 버전 pod 로만 요청이 가게 된다.

 > Service Endpoint 에서 추가/제거 되는 기준은 pod 가 `READY` 인지 아닌지 이다. 우선 `curl` 로 요청을 계속 보내고 있는 상태에서 버그가 있는 버전으로 rolling update 를 해보니 중간에 에러가 난 요청들이 보이긴 했다.
->
+> 
 > 4번째 요청까지는 OK 응답이 돌아오므로, readiness probe 가 이 pod 는 `READY` 라고 했을 것이다. 그러면서 Service Endpoints 에 이 pod 의 IP 가 추가된 것이며, 내가 보낸 `curl` 요청을 받을 수 있었던 것이다.
->
+> 
 > Readiness probe 는 주기적으로 실행되므로, 어느 시점부터 실패했을 것이므로 `READY` 상태가 아니게 되고 unavailable 상태가 지속되면서 rollout 은 중단된 것이다.
->
+> 
 > 결국 중간에 요청이 비정상적으로 처리되는 경우가 있었다는 것은 실제 서비스에서 일부 사용자들은 오류를 겪을 수도 있다는 것인데 이것이 불가피한 것인지 아닌지는 상황에 따라 다를 것 같다. 책에서는 모든 pod 가 잘못된 pod 로 교체되는 것에 비하면 낫다고 하는데, 이렇게 생각해도 과연 괜찮을련지 ㅋㅋ

 #### Rollout deadline
@@ -463,6 +473,7 @@ kubia-bcf9bb974-k7cxf    1/1     Running   0          7m14s
 Rollout 이 10분간 진전이 없으면 failed 처리된다. `kubectl describe` 로 확인해 보면 `ProgressDeadlineExceeded` condition 이 발생해있다.

 > `kubectl rollout status` 에서는 다음과 같이 에러가 발생한다.
+> 
 > ```
 > $ kubectl rollout status deployment kubia
 > error: deployment "kubia" exceeded its progress deadline
@@ -487,4 +498,4 @@ Rollout 이 10분간 진전이 없으면 failed 처리된다. `kubectl describe`
 ### Canary Release

 - https://martinfowler.com/bliki/CanaryRelease.html
-  - 일부 사용자들에게만 new version 으로 서비스 하는 것
+  - 일부 사용자들에게만 new version 으로 서비스 하는 것
--- a/_posts/Development/Kubernetes/2021-05-17-10-statefulsets.md
+++ b/_posts/Development/Kubernetes/2021-05-17-10-statefulsets.md
@@ -7,10 +7,12 @@ title: "10. StatefulSets: Deploying Replicated Stateful Applications"
 date: "2021-05-17"
 github_title: "2021-05-17-10-statefulsets"
 image:
-  path: /assets/img/posts/k8s-10.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-10.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-10.jpeg](../../../assets/img/posts/k8s-10.jpeg) _A stateful pod may be rescheduled to a different node, but it retains the name, hostname, and storage. (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-10)_
+![k8s-10.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-10.jpeg) _A stateful pod may be rescheduled to a different node, but it retains the name, hostname, and storage. (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-10)_

 ### 주요 내용

@@ -19,6 +21,7 @@ image:
 - DNS SRV record 를 이용한 peer discovery

 ## 10.1 Replicating stateful pods
+
 ---

 도입 질문: 각 pod replica 가 하나씩 PV 를 갖게 할 수는 없을까?
@@ -60,6 +63,7 @@ Kubernetes 의 철학에 어긋난다.
 Kubernetes 에서는 이러한 문제를 **StatefulSet** 으로 해결한다.

 ## 10.2 Understanding StatefulSets
+
 ---

 이런 경우, ReplicaSet 보다는 StatefulSet 을 사용하여 각 pod 들이 stable 한 이름과 상태를 갖도록 한다.
@@ -146,11 +150,12 @@ StatefulSet 들이 무엇을 보장해주는지 살펴본다.

 따라서 Kubernetes 에서는 같은 정보를 가지고 같은 PVC 에 bind 된 stateful pod 가 동시에 2개 이상 존재하지 않도록 특별히 주의한다. 즉 StatefulSet 은 stateful pod 가 최대 1개만 존재하도록 보장해야 하며, 이를 *at-most-one* semantics 라고 한다.

-따라서 StatefulSet 의 입장에서는 새로운 pod 를 생성하기 전에 생성할 pod 의 정보와 같은 정보를 가진 pod 가 없음을 **확신**할 수 있어야 한다. 이 때문에 노드에 문제가 생기는 경우 처리 방법이 크게 달라진다. 
+따라서 StatefulSet 의 입장에서는 새로운 pod 를 생성하기 전에 생성할 pod 의 정보와 같은 정보를 가진 pod 가 없음을 **확신**할 수 있어야 한다. 이 때문에 노드에 문제가 생기는 경우 처리 방법이 크게 달라진다.

 뒤에서 더 자세히 살펴보고, 우선 StatefulSet 을 생성하는 방법부터 살펴본다.

 ## 10.3 Using a StatefulSet
+
 ---

 ### 10.3.1 Creating the app and container image
@@ -383,6 +388,7 @@ Data stored on this pod: No data posted yet
 다만 random 한 pod 에서 응답을 보내준다.

 ## 10.4 Discovering peers in a StatefulSet
+
 ---

 마지막으로 살펴볼 내용은 peer discovery 이다. StatefulSet 의 pod 이 다른 pod 를 발견할 수 있어야 한다. 물론 API server 를 사용할수도 있겠지만, 애플리케이션이 직접 요청을 보내게 되기 때문에 Kubernetes 에 종속되게 된다. 다른 방법이 필요하며, 여기서는 SRV record 를 사용할 것이다.
@@ -472,6 +478,7 @@ Data stored in the cluster:
 Pod 가 직접 peer discovery 를 진행하므로 scaling 에도 유연하게 대처할 수 있다.

 ## 10.5 Understanding how StatefulSets deal with node failures
+
 ---

 10.2.4 에서 *at-most-one* semantics 를 설명하면서 StatefulSet 은 같은 상태를 가진 pod 를 2개 만들어서는 안된다고 했었다. 한편 노드가 작동을 중단하는 경우 Kubernetes 는 그 노드에 있던 리소스의 정보를 알 수 없게 된다. Pod 가 실제로 작동을 중지한 것인지, 아니면 접근이 가능한데 그냥 Kubelet 이 노드의 상태를 master 에 보고하는 것을 중단했을 수도 있다.
@@ -494,7 +501,7 @@ minikube 에서는 안된다! GKE 의 이야기이다.

 만약 노드의 네트워크가 금방 다시 연결되면 pod 상태를 다시 보고할 것이므로 `Ready` 상태가 된다. 반면 오랜 시간동안 (이 시간은 설정 가능하다) `Unknown` 상태이면 Kubernetes control plane 에서 pod 를 자동으로 삭제한다.

-Kubelet 이 pod 이 삭제 명령을 받으면 삭제를 시작하여 `Terminating` 으로 변경되는데, 지금 상황에서는 네트워크가 유실되었으므로 Kubelet 이 pod 삭제 명령을 알 수 없다. 그래서 pod 는 게속 실행 중이게 된다. 
+Kubelet 이 pod 이 삭제 명령을 받으면 삭제를 시작하여 `Terminating` 으로 변경되는데, 지금 상황에서는 네트워크가 유실되었으므로 Kubelet 이 pod 삭제 명령을 알 수 없다. 그래서 pod 는 게속 실행 중이게 된다.

 `kubectl describe pod <NAME>` 으로 유실된 노드의 pod 를 살펴보면 `Terminating` 으로 변경되어있고, `Reason: NodeLost` 라고 적혀있다. 단, 이는 어디까지나 control plane 의 관점이며, 실제로 노드 안에서 pod 는 정상적으로 돌아가고 있다.

--- a/_posts/Development/Kubernetes/2021-05-30-11-k8s-internals.md
+++ b/_posts/Development/Kubernetes/2021-05-30-11-k8s-internals.md
@@ -7,10 +7,12 @@ title: "11. Understanding Kubernetes Internals"
 date: "2021-05-30"
 github_title: "2021-05-30-11-k8s-internals"
 image:
-  path: /assets/img/posts/k8s-11.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-11.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-11.jpeg](../../../assets/img/posts/k8s-11.jpeg) _The chain of events that unfolds when a Deployment resource is posted to the API server (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-11)_
+![k8s-11.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-11.jpeg) _The chain of events that unfolds when a Deployment resource is posted to the API server (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-11)_

 ### 주요 내용

@@ -21,6 +23,7 @@ image:
 Kubernetes 리소스들이 어떻게 구현되었는지 살펴보자!

 ## 11.1 Understanding the architecture
+
 ---

 Kubernetes 클러스터는 다음과 같이 구성되어 있음을 1장에서 배웠다!
@@ -45,7 +48,7 @@ Kubernetes 클러스터는 다음과 같이 구성되어 있음을 1장에서

 ### 11.1.1 The distributed nature of Kubernetes components

-위에서 언급한 컴포넌트들은 각각 별도의 프로세스로 실행된다! 
+위에서 언급한 컴포넌트들은 각각 별도의 프로세스로 실행된다!

 #### 컴포넌트의 통신 방식

@@ -68,7 +71,7 @@ Kubernetes 를 사용하면서 리소스를 생성하고 수정하게 되면 이
 etcd 와 통신하는 유일한 컴포넌트는 API server 이고, 나머지 컴포넌트들은 API server 를 통해 간접적으로 etcd 에 접근하게 된다. 이렇게 구현된 이유는 validation 과 more robust optimistic locking system, 그리고 저장소와의 통신을 API server 에게 맡겨서 abstraction 의 효과를 얻기 위해서이다.

 > **Optimistic Concurrency Control** (Optimistic Locking): 데이터에 lock 을 걸어서 read/write 를 제한하지 않고, 데이터에 버전을 추가하는 방식이다. 대신 데이터가 수정될 때마다 버전이 증가하게 되며, 클라이언트가 데이터를 수정하려 할 때 데이터를 읽을 때와 쓰려고 할 때 버전을 비교하여 만약 다르다면 업데이트가 기각당하는 방식이다. 이 때 클라이언트는 데이터를 다시 읽어와서 업데이트를 다시 시도해야 한다.
->
+> 
 > 모든 Kubernetes 리소스에는 `metadata.resourceVersion` field 가 있어 클라이언트 쪽에서 API server 에 업데이트 요청을 보낼 때 반드시 함께 전달해야 한다. 만약 etcd 에 저장된 버전과 다르다면, 업데이트가 기각된다.

 #### etcd 에 리소스가 저장되는 방식
@@ -100,7 +103,7 @@ $ etcdctl ls /registry/pods
 /registry/pods/kube-system
 ```

-Namespace 별로 구분이 되어있는 것을 확인할 수 있고, 더욱 자세히 확인하면 
+Namespace 별로 구분이 되어있는 것을 확인할 수 있고, 더욱 자세히 확인하면

 ```
 $ etcdctl ls /registry/pods/default
@@ -192,7 +195,7 @@ Acceptable 인지 아닌지 판단하기 위해서는 미리 정의된 조건들

 위에서 다양한 조건으로 검사를 했지만, 그럼에도 불구하고 어떤 노드는 더 나은 선택일 수도 있다. 2-노드 클러스터가 있다고 하면, 둘다 acceptable 인데 한 노드가 10개의 pod 를 이미 실행하고 있는 반면 나머지 하나는 실행 중인 pod 가 없다고 하자. 그러면 자연스럽게 실행 중인 pod 가 없는 쪽으로 scheduling 을 할 것이다.

-하지만 클라우드에서 실행하는 경우라면, 그냥 10개 pod 를 실행 중인 노드에 scheduling 하고 나머지 node 는 없애서 cloud provider 에게 메모리를 돌려주는 것이 나을 수도 있다. 
+하지만 클라우드에서 실행하는 경우라면, 그냥 10개 pod 를 실행 중인 노드에 scheduling 하고 나머지 node 는 없애서 cloud provider 에게 메모리를 돌려주는 것이 나을 수도 있다.

 #### Multiple schedulers

@@ -318,6 +321,7 @@ Kubernetes 시스템이 각 역할과 책임을 가진 개별적인 컴포턴트
 사용자가 정의한 목표 상태에 클러스터가 도달할 수 있도록 컴포넌트들이 협동한다.

 ## 11.2 How controllers cooperate
+
 ---

 Pod 를 생성할 때 어떤 일이 일어나는지 자세히 살펴본다. Pod 를 직접 생성하는 경우는 잘 없으므로, Deployment 를 생성하는 경우를 살펴볼 것이다.
@@ -363,6 +367,7 @@ ReplicaSet controller 가 새로운 ReplicaSet 을 감지하고, pod selector
 명령어를 입력해 보면 `SOURCE` 에 어떤 컴포넌트/controller 가 event 를 발생시켰는지, `KIND`, `NAME` 에서 event 가 영향을 미친 리소스의 종류와 이름을 확인할 수 있다. `REASON` 과 `MESSAGE` 에서는 상세한 설명을 확인할 수 있게 된다.

 ## 11.3 Understanding what a running pod is
+
 ---

 Pod 를 실행했으므로, *실행중인 pod* 가 무엇인지 살펴보자. Kubelet 이 컨테이너를 실행하는 것은 알았는데, 더 할 일이 있을까?
@@ -374,6 +379,7 @@ Pod 내의 컨테이너는 linux namespace 와 네트워크를 공유하기 때
 Pod 내의 컨테이너는 재시작 되는 경우가 많다. 이 때 같은 linux namespace 로 재시작 되어야 하는데, 위와 같이 infrastructure 컨테이너가 존재하기 때문에 같은 linux namespace 를 사용할 수 있게 된다. 이 infrastructure 컨테이너는 pod 와 lifecycle 이 같기 때문에 pod 가 삭제될 때 같이 지워진다. 만약 infrastructure 컨테이너를 삭제하면 Kubelet 이 다시 만들어 주고, pod 의 컨테이너도 전부 다시 만든다.

 ## 11.4 Inter-pod networking
+
 ---

 Pod 들은 고유 IP 를 가지며, NAT 없이 flat network 구조를 갖는다. 작동 원리를 살펴본다.
@@ -423,12 +429,13 @@ SDN 을 사용하게 되면 노드들이 같은 네트워크 스위치에 연결
 플러그인 설치는DaemonSet 과 기타 리소스를 포함한 YAML 파일을 생성하면 된다. 참고로 Kubelet 실행시 `--network-plugin=cni` 로 옵션을 줘야 한다.

 ## 11.5 How services are implemented
+
 ---

 복습!

 - 각 service 는 stable IP 주소와 포트를 갖고, 클라이언트는 이 주소로 연결하여 service 를 사용한다.
- IP 주소는 가상 IP 주소로, 네트워크 인터페이스에 할당되어있지 않고, 노드 밖으로 나가는 패킷에 source/destination IP 로 들어가지 않는다. 
+- IP 주소는 가상 IP 주소로, 네트워크 인터페이스에 할당되어있지 않고, 노드 밖으로 나가는 패킷에 source/destination IP 로 들어가지 않는다.

 ### 11.5.1 Introducing the kube-proxy

@@ -453,6 +460,7 @@ kube-proxy 는 service 의 변화만 watch 하고 있는 것은 아니고, Endpo
 그러므로 이 패킷의 목적지는 service 의 endpoint 중 한 pod 의 주소와 포트로 변경된다. 이때부터는 마치 클라이언트에서 선택된 pod 로 직접 (directly) 요청을 보낸 것처럼 보이게 된다.

 ## 11.6 Running highly available clusters
+
 ---

 Kubernetes 를 사용하는 이유 중 하나로 인프라에 문제가 생겨도 중단 없이 서비스를 유지할 수 있다는 점이 있다. 중단 없이 서비스를 유지하기 위해서는 앱이 계속 실행되고 있어야 하기도 하지만, 노드에 있는 Control Plane 컴포넌트들이 잘 작동해 줘야 한다. 고가용성 (HA) 를 달성하기 위해 어떤 것들이 관련되어 있는지 살펴볼 것이다.
@@ -497,7 +505,7 @@ API server 를 복제하는 것은 더 쉽다! API server 는 거의 stateless

 #### Understanding the leader election mechanism used in Control Plane components

-여기서 흥미로운 점은 leader election 을 위해 컴포넌트들이 서로 통신하지 않아도 된다는 점이다. Leader election 의 동작 과정을 보면 API server 에 Endpoints 리소스를 만들어서 한다. (저자는 Endpoints 리소스를  그렇게 쓰는거 아니라는 의미에서 *abused* 라고 표현했다. 다른 리소스를 사용했어도 괜찮았을 것이라고 한다.)
+여기서 흥미로운 점은 leader election 을 위해 컴포넌트들이 서로 통신하지 않아도 된다는 점이다. Leader election 의 동작 과정을 보면 API server 에 Endpoints 리소스를 만들어서 한다. (저자는 Endpoints 리소스를 그렇게 쓰는거 아니라는 의미에서 *abused* 라고 표현했다. 다른 리소스를 사용했어도 괜찮았을 것이라고 한다.)

 `kube-scheduler` 라는 이름을 가진 Endpoints 리소스를 확인해 보면 annotation 으로 `control-plane.alpha.kubernetes.io/leader` 를 가지고 있는 것을 확인할 수 있다. 여기에 `holderIdentity` 라는 필드가 있는데, 여기에 현재 leader 의 이름이 들어간다.

--- a/_posts/Development/Kubernetes/2021-06-06-12-securing-k8s-api-server.md
+++ b/_posts/Development/Kubernetes/2021-06-06-12-securing-k8s-api-server.md
@@ -7,10 +7,12 @@ title: "12. Securing the Kubernetes API Server"
 date: "2021-06-06"
 github_title: "2021-06-06-12-securing-k8s-api-server"
 image:
-  path: /assets/img/posts/k8s-12.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-12.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-12.jpeg](../../../assets/img/posts/k8s-12.jpeg) _Roles grant permissions, whereas RoleBindings bind Roles to subjects (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-12)_
+![k8s-12.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-12.jpeg) _Roles grant permissions, whereas RoleBindings bind Roles to subjects (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-12)_

 ### 주요 내용

@@ -18,6 +20,7 @@ image:
 - RBAC plugin, Role/RoleBinding, ClusterRole/ClusterRoleBinding 에 대한 이해

 ## 12.1 Understanding authentication
+
 ---

 API server 가 요청을 받게 되면, authentication plugin 을 거치며 요청을 보낸 주체가 누구인지 분석한다.
@@ -125,6 +128,7 @@ Image pull secret 은 private image repository 에서 image 를 pull 받을 때
 Pod definition 에서 `.spec.serviceAccountName` 필드에 적어주면 된다. Pod 생성할 때 미리 정해야 하며, pod 가 생성된 뒤에는 수정할 수 없다.

 ## 12.2 Securing the cluster with role-based access control
+
 ---

 Role-based access control (RBAC) plugin 을 사용하게 되면, unauthorized user 가 클러스터의 상태를 조회하거나 수정하는 것을 막을 수 있다. RBAC 를 사용하여 클러스터의 authorization 을 관리하는 방법을 살펴본다.
--- a/_posts/Development/Kubernetes/2021-06-29-13-securing-nodes-and-network.md
+++ b/_posts/Development/Kubernetes/2021-06-29-13-securing-nodes-and-network.md
@@ -7,10 +7,12 @@ title: "13. Securing Cluster Nodes and the Network"
 date: "2021-06-29"
 github_title: "2021-06-29-13-securing-nodes-and-network"
 image:
-  path: /assets/img/posts/k8s-13.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-13.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-13.jpeg](../../../assets/img/posts/k8s-13.jpeg) _A pod with hostNetwork: true uses the node's network interfaces instead of its own. (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-13)_
+![k8s-13.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-13.jpeg) _A pod with hostNetwork: true uses the node's network interfaces instead of its own. (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-13)_

 ### 주요 내용

@@ -20,6 +22,7 @@ image:
 컨테이너는 독립적인 환경을 제공한다고 하긴 했지만, 공격자가 API server 에 접근하게 되면 컨테이너에 무엇이든 집어넣고 악의적인 코드를 실행할 수 있고, 이는 실행 중인 다른 컨테이너에 영향을 줄 수도 있다!

 ## 13.1 Using the host node's namespaces in a pod
+
 ---

 컨테이너는 별도의 linux namespace 에서 실행된다고 했었다.
@@ -64,6 +67,7 @@ spec:
 호스트의 네트워크 namespace 를 사용할 수 있었던 것처럼 `hostPID`, `hostIPC` 값을 `true` 로 설정해 주면 노드의 PID 와 IPC namespace 를 사용하게 된다. `spec` 아래에 넣어주면 된다.

 ## 13.2 Configuring the container's security context
+
 ---

 `securityContext` property 를 이용하면 보안과 관련된 기능들을 pod 과 내부 컨테이너에 설정할 수 있다.
@@ -271,6 +275,7 @@ total 4
 > `supplementalGroups` 에 대한 설명이 좀 부족하다. 단순히 user 와 엮인 추가 group ID 를 설정할 수 있다고만 적혀있다.

 ## 13.3 Restricting the use of security-related features in pods
+
 ---

 클러스터 관리자는 PodSecurityPolicy 리소스를 이용해서 pod 의 보안과 관련된 기능들을 제한할 수 있다.
@@ -387,11 +392,12 @@ $ kubectl create clusterrolebinding <CLUSTER_ROLE_BINDING_NAME> \
  --clusterrole=<CLUSTER_ROLE_NAME> --group=<GROUP_NAME>
 ```

-> `kubectl` 에서 사용자를 추가하려면 `kubectl config set-credentials <NAME> --username=<USERNAME> --password=<PASSWORD>` 를 입력하면 된다.
+> `kubectl` 에서 사용자를 추가하려면 `kubectl config set-credentials <NAME> --username=<USERNAME> --password=<PASSWORD> ` 를 입력하면 된다.

 > 다른 사용자의 이름으로 리소스를 생성하려면 `kubectl --user <USERNAME> create` 를 하면 된다.

 ## 13.4 Isolating the pod network
+
 ---

 앞서 살펴본 방법들은 pod 와 컨테이너 단에서 적용되는 보안 관련 설정을 살펴봤다. 이번에는 pod 사이의 네트워크 통신 측면에서 보안을 적용하는 방법을 알아본다.
--- a/_posts/Development/Kubernetes/2021-07-11-14-managing-computation-resources.md
+++ b/_posts/Development/Kubernetes/2021-07-11-14-managing-computation-resources.md
@@ -7,10 +7,12 @@ title: "14. Managing Pods' Computational Resources"
 date: "2021-07-11"
 github_title: "2021-07-11-14-managing-computation-resources"
 image:
-  path: /assets/img/posts/k8s-14.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-14.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-14.jpeg](../../../assets/img/posts/k8s-14.jpeg) _The Scheduler only cares about requests, not actual usage. (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-14)_
+![k8s-14.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-14.jpeg) _The Scheduler only cares about requests, not actual usage. (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-14)_

 ### 주요 내용

@@ -21,6 +23,7 @@ image:
 각 pod 가 어느 정도의 자원(CPU/메모리)을 소모할지 파악하고, 이를 적절히 제한하는 것은 pod 정의에서 굉장히 중요한 부분이다.

 ## 14.1 Requesting resources for a pod's containers
+
 ---

 Pod 를 생성할 때 **requests** 와 **limits** 를 정할 수 있다.
@@ -126,6 +129,7 @@ Allocatable:
 Kubernetes 에서는 사용자 지정 resource 를 정의해서 requests 에 포함할 수 있다. (Extended Resources since version 1.8)

 ## 14.2 Limiting resources available to a container
+
 ---

 이번에는 자원의 최대 사용량을 제한해 본다.
@@ -194,6 +198,7 @@ CPU도 문제가 되는 경우가 있는데, 코어 수를 참고하여 worker t
 이러한 경우 Kubernetes Downward API 를 이용해서 CPU limit 값을 애플리케이션에 넘겨주는 식으로 해결할 수 있다.

 ## 14.3 Understanding pod QoS classes
+
 ---

 위에서 limits 의 경우 100% 를 초과할 수 있다고 했는데, 초과하면 어떤 컨테이너나 pod 를 kill 해야 한다고 했다. 어떤 pod 가 kill 되는지는 내부적으로 정해져 있다.
@@ -241,6 +246,7 @@ OOM score 의 계산에는 2가지 요인이 들어간다.
 잡은 메모리 중 사용 비율이 높을수록 먼저 kill 된다.

 ## 14.4 Setting default requests and limits for pods per namespace
+
 ---

 requests/limits 를 설정하지 않으면 kill 의 대상이 될 수 있으므로 설정하는 것이 좋다. 각 컨테이너에 이를 설정하는 것은 번거로우므로, Kubernetes 에서는 LimitRange 리소스를 제공한다.
@@ -303,6 +309,7 @@ LimitRange 리소스를 생성한 뒤 range 를 벗어난 pod 를 생성하려
 LimitRange 는 namespaced resource 이므로 한 namespace 에만 적용된다. 따라서 namespace 별로 LimitRange 를 만들어 두면 제한을 다르게 할 수 있다.

 ## 14.5 Limiting the total resources available in a namespace
+
 ---

 LimitRange 는 pod 전체의 리소스 총합을 제한하지는 못한다. 하지만 클러스터 관리자 입장에서는 namespace 별로 리소스 총량을 제한할 필요가 있기 때문에, Kubernetes 에서는 ResourceQuota object 가 제공된다.
@@ -400,6 +407,7 @@ spec:
 `BestEffort` 의 경우 pod 의 개수만 제한할 수 있다. (애초에 requests/limits 가 세팅되지 않음) 나머지 3개 클래스의 경우 pod 개수 뿐만 아니라 CPU/메모리 requests/limits 모두 제한할 수 있다.

 ## 14.6 Monitoring pod resource usage
+
 ---

 requests/limits 를 적절하게 설정하려면 pod 에서 자원이 얼마나 사용되고 있는지 확인해야 하고 이를 모니터링해야 한다.
--- a/_posts/Development/Kubernetes/2021-07-18-15-autoscaling.md
+++ b/_posts/Development/Kubernetes/2021-07-18-15-autoscaling.md
@@ -7,10 +7,12 @@ title: "15. Automatic Scaling of Pods and Cluster Nodes"
 date: "2021-07-18"
 github_title: "2021-07-18-15-autoscaling"
 image:
-  path: /assets/img/posts/k8s-15.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-15.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-15.jpeg](../../../assets/img/posts/k8s-15.jpeg)  _How the autoscaler obtains metrics and rescales the target deployment (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-15)_
+![k8s-15.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-15.jpeg) _How the autoscaler obtains metrics and rescales the target deployment (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-15)_

 ### 주요 내용

@@ -22,6 +24,7 @@ image:
 이번 장에서는 pod 나 노드의 상태에 따라 자동으로 scaling 하는 방법을 알아본다.

 ## 15.1 Horizontal pod autoscaling
+
 ---

 Horizontal pod autoscaling 은 **Horizontal controller** 가 pod 의 replica 수를 알아서 조절하는 것이다.
@@ -75,6 +78,7 @@ HPA 를 실제로 생성하기 위해서는 다음 명령어를 입력하면 된
 ```bash
 $ kubectl autoscale deployment <DEPLOYMENT_NAME> --cpu-percent=<PERCENT> --min=<MIN> --max=<MAX>
 ```
+
 - `PERCENT` 는 target value 로 지정할 CPU utilization 이다.
 - `MIN`, `MAX` 는 scaling 으로 조절할 수 있는 pod 개수의 최솟값/최댓값이다.

@@ -156,6 +160,7 @@ https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkth
 > Documentation 에서는 특별한 언급을 찾지는 못했다. 일단 `autoscale` 명령어로 `--min=0` 을 주고 생성해도 1 로 설정하는 것이 확인되었다.

 ## 15.2 Vertical pod autoscaling
+
 ---

 만약 vertical scaling 이 지원됐다면, pod manifest 에서 resource requests 를 수정하는 방식으로 지원했을 것이라고 한다. 하지만 이미 생성된 pod 의 resource requests 는 수정이 불가능하다.
@@ -175,6 +180,7 @@ Experimental feature 중에, 새로 생성된 pod 의 CPU/메모리 requests 를
 책이 쓰여질 당시 vertical pod autoscaling proposal 이 finalize 되고 있었다고 한다. 공식 문서를 참고해 달라고 한다.

 ## 15.3 Horizontal scaling of cluster nodes
+
 ---

 Scaling 을 하다 보면 존재하는 노드의 자원을 다 쓰거나 기타 이유로 scheduling 이 불가능해지는 상황이 올 수도 있다.
@@ -201,7 +207,7 @@ Scheduler 가 scheduling 에 실패했을 때, Cluster Autoscaler 가 동작하

 노드가 삭제될 것이라고 마킹되면, unschedulable 이라고 마킹되며, pod 들은 전부 삭제된다. 삭제되기 위해서는 애초에 모든 pod 들이 Replication 에 의해 관리되고 있었을 것이므로, 삭제된 pod 대신 다른 노드에 pod 가 자동으로 띄워진다.

-> `kubectl cordon <node>` 를 하면 노드가 unschedulable 상태가 된다. 하지만 pod 들은 남아있는다. `kubectl drain <node>` 를 하면 unschedulable 상태가 되고 pod 가 전부 삭제된다.
+> `kubectl cordon <node> ` 를 하면 노드가 unschedulable 상태가 된다. 하지만 pod 들은 남아있는다. `kubectl drain <node> ` 를 하면 unschedulable 상태가 되고 pod 가 전부 삭제된다.

 ### 15.3.2 Enabling the Cluster Autoscaler

@@ -216,6 +222,7 @@ Pod label selector 와 최솟값을 설정해서 생성하면 selector 에 매
 ```bash
 $ kubectl create pdb <NAME> --selector=<SELECTOR> --min-available=<MIN>
 ```
+
 - `SELECTOR` 는 pod label selector (`key=value`)
 - `MIN` 은 사용 가능한 pod 개수의 최솟값

--- a/_posts/Development/Kubernetes/2021-08-15-16-advanced-scheduling.md
+++ b/_posts/Development/Kubernetes/2021-08-15-16-advanced-scheduling.md
@@ -7,10 +7,12 @@ title: "16. Advanced Scheduling"
 date: "2021-08-15"
 github_title: "2021-08-15-16-advanced-scheduling"
 image:
-  path: /assets/img/posts/k8s-16.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-16.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-16.jpeg](../../../assets/img/posts/k8s-16.jpeg) _A pod is only scheduled to a node if it tolerates the node’s taints. (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-16)_
+![k8s-16.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-16.jpeg) _A pod is only scheduled to a node if it tolerates the node’s taints. (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-16)_

 ### 주요 내용

@@ -19,6 +21,7 @@ image:
 - Pod affinity, anti-affinity 사용

 ## 16.1 Using taints and tolerations to repel pods from certain nodes
+
 ---

 Pod 가 특정 노드에 schedule 되기 위해서는 그 노드의 taint 를 tolerate 할 수 있어야 한다.
@@ -87,6 +90,7 @@ Taint 를 사용하면 `NoSchedule` effect 를 이용해 새로운 pod 들이
 이외에도 taint/toleration 을 이용해서 클러스터를 분할해서 여러 팀이 사용하게 할 수 있다.

 ## 16.2 Using node affinity to attract pods to certain nodes
+
 ---

 Taint 를 이용하면 특정 노드에 pod 이 scheduling 되지 않도록 할 수 있었다. 반면 **node affinity** 를 이용하면 pod 가 schedule 될 수 있는 노드를 정할 수 있다.
@@ -170,6 +174,7 @@ spec:
 4. 이외의 노드

 ## 16.3 Co-locating pods with pod affinity and anti-affinity
+
 ---

 앞서 살펴본 node affinity 는 pod 과 노드 사이의 affinity 를 정한 것이었는데, 때로는 pod 사이의 affinity 가 필요할 때도 있다. 예를 들어 프론트엔드/백엔드 pod 를 같은 노드에 띄우면 latency 가 줄어들게 될 것이다. 그렇다고 두 pod 를 특정 노드에 띄우라고 지시하기 보다는 Kubernetes 가 알아서 하라고 하는 것이 좋을 것이다.
--- a/_posts/Development/Kubernetes/2021-08-15-17-best-practices.md
+++ b/_posts/Development/Kubernetes/2021-08-15-17-best-practices.md
@@ -7,10 +7,12 @@ title: "17. Best Practices for Developing Apps"
 date: "2021-08-15"
 github_title: "2021-08-15-17-best-practices"
 image:
-  path: /assets/img/posts/k8s-17.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-17.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-17.jpeg](../../../assets/img/posts/k8s-17.jpeg) _Resources in a typical application (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-17)_
+![k8s-17.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-17.jpeg) _Resources in a typical application (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-17)_

 ### 주요 내용

@@ -18,6 +20,7 @@ image:
 - Pod lifecycle hooks and init containers

 ## 17.1 Bringing everything together
+
 ---

 일반적인 애플리케이션이 Kubernetes 위에서 배포될 때 어떤 형태로 하는지, 지금까지 살펴본 것들을 종합하여 알아본다.
@@ -35,6 +38,7 @@ Service 를 이용해서 외부에서 pod 로 요청을 보낼 수 있도록 하
 Kubernetes resource 에는 주로 label 을 붙여서 관리하고, 또 대부분 annotation 을 가지고 있어 메타데이터를 저장하여 운영 및 관리를 할 수 있게 해준다.

 ## 17.2 Understanding the pod's lifecycle
+
 ---

 Pod 와 VM 의 가장 큰 차이점 중 하나는 pod 는 얼마든지 삭제되었다 다시 생성할 수 있다는 점이다. Pod 를 다른 노드로 옮기거나, scale down 이 일어났을 때 pod 를 삭제하곤 한다.
@@ -184,6 +188,7 @@ StatefulSet 을 사용하면 PVC 를 다시 사용할 수 있기는 하지만, s
 > 얘도 문제가 생기는 경우는 어떻게 하나요...

 ## 17.3 Ensuring all client requests are handled properly
+
 ---

 당연히 client 의 요청은 잘 처리해야 한다.
@@ -219,6 +224,7 @@ Shutdown 을 위해서 다음 절차를 밟아야 한다.
 - 종료한다.

 ## 17.4 Making your apps easy to run and manage in Kubernetes
+
 ---

 ### 17.4.1 Making manageable container images
@@ -286,6 +292,7 @@ Sidecar 컨테이너에 로그를 처리해주는 프로세스를 띄워도 된
 해결 방법으로는 JSON 로그는 파일로 내보내고, `stdout` 에는 원본을 찍어 사람이 보기 편하도록 하면 된다.

 ## 17.5 Best practices for development and testing
+
 ---

 정해진 정답은 없지만, 권장 사항을 몇 가지 살펴본다. 각자 환경에 알맞은 방법을 택하면 된다.
--- a/_posts/Development/Kubernetes/2021-09-04-18-extending-k8s.md
+++ b/_posts/Development/Kubernetes/2021-09-04-18-extending-k8s.md
@@ -7,10 +7,12 @@ title: "18. Extending Kubernetes"
 date: "2021-09-04"
 github_title: "2021-09-04-18-extending-k8s"
 image:
-  path: /assets/img/posts/k8s-18.jpeg
+  path: /assets/img/posts/Development/Kubernetes/k8s-18.jpeg
+attachment:
+  folder: assets/img/posts/Development/Kubernetes
 ---

-![k8s-18.jpeg](../../../assets/img/posts/k8s-18.jpeg) _API Server Aggregation (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-18)_
+![k8s-18.jpeg](../../../assets/img/posts/Development/Kubernetes/k8s-18.jpeg) _API Server Aggregation (출처: https://livebook.manning.com/book/kubernetes-in-action/chapter-18)_

 ### 주요 내용

@@ -19,6 +21,7 @@ image:
 - OpenShift, Deis Workflow, Helm

 ## 18.1 Defining custom API objects
+
 ---

 지금까지 책에서 살펴본 Kubernetes object 들은 비교적으로 low-level 한 object 이고 일반적인 개념을 다룬다.
@@ -222,6 +225,7 @@ APIService 를 등록하고 나면, `apiVersion` 값이 `extensions.example.com/
 필요하다면 `kubectl` 과 같은 CLI tool 을 자체 개발하여 custom resource 에 대한 더욱 풍부한 제어를 할 수도 있다.

 ## 18.2 Extending Kubernetes with the Kubernetes Service Catalog
+
 ---

 Kubernetes 에서 '서비스' (Service 리소스 아님) 를 만들고 싶다면, 사용자가 pod, Service, Secret 등을 직접 만들어서 배포하거나, 혹은 이를 배포해 달라고 Ops 팀에 요청해야 했다.
@@ -359,6 +363,7 @@ Service Catalog 는 서비스 제공자들이 Kubernetes 를 통해 서비스를
 해당 서비스가 쉽게 생성되기 때문에 애플리케이션 배포에 더욱 유용하게 사용할 수 있다.

 ## 18.3 Platforms built on top of Kubernetes
+
 ---

 이처럼 Kubernetes 는 굉장히 유연하고 확장 가능한 시스템이지만, 몇몇 회사들은 플랫폼을 자체 개발하여 Kubernetes 위에서 동작하게 하고, 이를 서비스로 제공하고 있다. (PaaS, Platform-as-a-Service)
@@ -439,4 +444,4 @@ Chart 는 애플리케이션 설정을 담고 있는 Config 와 합쳐져 Releas

 ---

-마지막 장이다. 끝!
+마지막 장이다. 끝!
--- a/Theory/2023-01-11-algebra-of-sets.md
+++ b/Theory/2023-01-11-algebra-of-sets.md
@@ -8,10 +8,12 @@ title: "01. Algebra of Sets"
 date: "2023-01-11"
 github_title: "2023-01-11-algebra-of-sets"
 image:
-  path: /assets/img/posts/mt-01.png
+  path: /assets/img/posts/Mathematics/Measure Theory/mt-01.png
+attachment:
+  folder: assets/img/posts/Mathematics/Measure Theory
 ---

-![mt-01.png](../../../assets/img/posts/mt-01.png)
+![mt-01.png](../../../assets/img/posts/Mathematics/Measure%20Theory/mt-01.png)

 르벡 적분을 공부하기 위해서는 먼저 집합의 ‘길이’ 개념을 공부해야 합니다. 그리고 집합의 ‘길이’ 개념을 확립하기 위해서는 집합 간의 연산과 이에 대한 구조가 필요합니다.

@@ -198,9 +200,6 @@ $$\lim_ {n\rightarrow\infty} \mu(A_n) = \mu\left( \bigcap_ {n=1}^\infty A_n \rig
 이제 measure의 개념을 정리했으니 다음 글에서는 본격적으로 집합을 재보려고 합니다. 우리의 목표는 $\mathbb{R}^p$에서 measure를 정의하는 것입니다. 우선 쉽게 잴 수 있는 집합들부터 고려할 것입니다.

 [^1]: $\sigma$-ring 이면 불필요한 조건이지만, 일반적인 ring에 대해서는 필요한 조건입니다.
-
 [^2]: 증명은 해석개론, 김김계 책을 참고해주세요. 각 구간마다 유리수를 택할 수 있고, 유리수는 countable이기 때문에...
-
 [^3]: 확률의 덧셈정리와 유사합니다. 확률론 또한 measure theory와 관련이 깊습니다.
-
 [^4]: 무한하지 않다는 조건이 있어야 이항이 가능합니다.
--- a/Theory/2023-01-23-construction-of-measure.md
+++ b/Theory/2023-01-23-construction-of-measure.md
@@ -8,10 +8,12 @@ title: "02. Construction of Measure"
 date: "2023-01-23"
 github_title: "2023-01-23-construction-of-measure"
 image:
-  path: /assets/img/posts/mt-02.png
+  path: /assets/img/posts/Mathematics/Measure Theory/mt-02.png
+attachment:
+  folder: assets/img/posts/Mathematics/Measure Theory
 ---

-![mt-02.png](../../../assets/img/posts/mt-02.png)
+![mt-02.png](../../../assets/img/posts/Mathematics/Measure%20Theory/mt-02.png)

 이제 본격적으로 집합을 재보도록 하겠습니다. 우리가 잴 수 있는 집합들부터 시작합니다. $\mathbb{R}^p$에서 논의할 건데, 이제 여기서부터는 $\mathbb{R}$의 구간의 열림/닫힘을 모두 포괄하여 정의합니다. 즉, $\mathbb{R}$의 구간이라고 하면 $[a, b], (a, b), [a, b), (a, b]$ 네 가지 경우를 모두 포함합니다.

@@ -199,7 +201,7 @@ $$\mu^\ast(A) + \mu^\ast(B) = \mu^\ast(A\cup B) + \mu^\ast(A \cap B)$$

 와 같이 정의하면 $A_n$이 쌍마다 서로소이고 $A_n \in \mathfrak{M} _ F(\mu)$ 임을 알 수 있다.

-위 사실을 이용하여 $A_n \in \mathfrak{M} _  F(\mu)$ 에 대하여 $A = \displaystyle\bigcup_ {n=1}^\infty A_n$ 으로 두자.
+위 사실을 이용하여 $A_n \in \mathfrak{M} _ F(\mu)$ 에 대하여 $A = \displaystyle\bigcup_ {n=1}^\infty A_n$ 으로 두자.

 1. Countable subadditivity에 의해 $\displaystyle\mu^\ast(A) \leq \sum_ {n=1}^{\infty} \mu^\ast (A_n)$ 가 성립한다.

@@ -254,9 +256,6 @@ $$A_n \cap B = \bigcup_ {k=1}^\infty (A_n \cap B_k) \in \mathfrak{M}(\mu)$$
 이제 $\Sigma$ 위의 $\mu$ 정의를 $\mathfrak{M}(\mu)$ ($\sigma$-algebra)로 확장하여 $\mathfrak{M}(\mu)$ 위에서는 $\mu = \mu^\ast$ 로 정의합니다. $\Sigma$ 위에서 $\mu = m$ 일 때, 이와 같이 확장한 $\mathfrak{M}(m)$ 위의 $m$을 **Lebesgue measure** on $\mathbb{R}^p$라 합니다. 그리고 $A \in \mathfrak{M}(m)$ 를 Lebesgue measurable set이라 합니다.

 [^1]: $A$가 open이 아니면 자명하지 않은 명제입니다.
-
 [^2]: $A$가 $\mu$-measurable인데 $\mu^\ast(A) < \infty$이면 $A$는 finitely $\mu$-measurable이다.
-
 [^3]: $A$가 countable union of sets in $\mathfrak{M} _ F(\mu)$이므로 $\mu^\ast$도 각 set의 $\mu^\ast$의 합이 된다.
-
 [^4]: 아직 증명이 끝나지 않았습니다. $A_n$은 $\mathfrak{M}(\mu)$의 원소가 아니라 $\mathfrak{M} _ F(\mu)$의 원소입니다.
--- a/Theory/2023-01-24-measure-spaces.md
+++ b/Theory/2023-01-24-measure-spaces.md
@@ -8,14 +8,16 @@ title: "03. Measure Spaces"
 date: "2023-01-24"
 github_title: "2023-01-24-measure-spaces"
 image:
-  path: /assets/img/posts/mt-03.png
+  path: /assets/img/posts/Mathematics/Measure Theory/mt-03.png
+attachment:
+  folder: assets/img/posts/Mathematics/Measure Theory
 ---

 ## Remarks on Construction of Measure

 Construction of measure 증명에서 추가로 참고할 내용입니다.

-![mt-03.png](../../../assets/img/posts/mt-03.png)
+![mt-03.png](../../../assets/img/posts/Mathematics/Measure%20Theory/mt-03.png)

 **명제.** $A$가 열린집합이면 $A \in \mathfrak{M}(\mu)$ 이다. 또한 $A^C \in \mathfrak{M}(\mu)$ 이므로, $F$가 닫힌집합이면 $F \in \mathfrak{M}(\mu)$ 이다.

@@ -116,5 +118,4 @@ Uncountable인 경우에는 Cantor set $P$를 생각한다. $E_n$을 다음과
 > $A \subseteq B \subseteq X$ 일 때, $B \in \mathfrak{M}$ 이고 $\mu(B) = 0$ 이면 $A \in \mathfrak{M}$ 이다.

 [^1]: 첫 번째 부등식은 countable subadditivity, 두 번째 부등식은 $\mu^\ast$의 정의에서 나온다.
-
 [^2]: [Vitali set](https://en.wikipedia.org/wiki/Vitali_set) 참고.
--- a/Theory/2023-02-06-measurable-functions.md
+++ b/Theory/2023-02-06-measurable-functions.md
@@ -8,7 +8,9 @@ title: "04. Measurable Functions"
 date: "2023-02-06"
 github_title: "2023-02-06-measurable-functions"
 image:
-  path: /assets/img/posts/mt-04.png
+  path: /assets/img/posts/Mathematics/Measure Theory/mt-04.png
+attachment:
+  folder: assets/img/posts/Mathematics/Measure Theory
 ---

 Lebesgue integral을 공부하기 전 마지막 준비입니다. Lebesgue integral은 다음과 같이 표기합니다.
@@ -153,7 +155,7 @@ $$s(x) = \sum_ {i=1}^{n} c_i \chi_ {E_i}(x).$$

 여기서 $E_i$에 measurable 조건이 추가되면, 정의에 의해 $\chi_ {E_i}$도 measurable function입니다. 따라서 모든 measurable simple function을 measurable $\chi_ {E_i}$의 linear combination으로 표현할 수 있습니다.

-![mt-04.png](../../../assets/img/posts/mt-04.png)
+![mt-04.png](../../../assets/img/posts/Mathematics/Measure%20Theory/mt-04.png)

 아래 정리는 simple function이 Lebesgue integral의 building block이 되는 이유를 잘 드러냅니다. 모든 함수는 simple function으로 근사할 수 있습니다.

@@ -206,7 +208,5 @@ $$f_n + g_n \rightarrow f + g, \quad f_ng_n \rightarrow fg$$
 이고 measurability는 극한에 의해 보존되므로 $f+g, fg$는 measurable이다.

 [^1]: 일반적으로는 ‘measurable set의 preimage가 measurable이 될 때’로 정의합니다.
-
 [^2]: 참고로 $\infty - \infty$ 의 경우는 정의되지 않으므로 생각하지 않습니다.
-
 [^3]: 이 정의에서 $\infty - \infty$ 가 나타나지 않음에 유의해야 합니다.
--- a/Theory/2023-02-13-lebesgue-integration.md
+++ b/Theory/2023-02-13-lebesgue-integration.md
@@ -8,7 +8,9 @@ title: "05. Lebesgue Integration"
 date: "2023-02-13"
 github_title: "2023-02-13-lebesgue-integration"
 image:
-  path: /assets/img/posts/mt-05.png
+  path: /assets/img/posts/Mathematics/Measure Theory/mt-05.png
+attachment:
+  folder: assets/img/posts/Mathematics/Measure Theory
 ---

 ## Lebesgue Integration
@@ -119,7 +121,7 @@ $$\int f \,d{\mu} = \sup\left\lbrace \int h \,d{\mu}: 0\leq h \leq f, h \text{ m

 $f$보다 작은 measurable simple function의 적분값 중 상한을 택하겠다는 의미입니다. $f$보다 작은 measurable simple function으로 $f$를 근사한다고도 이해할 수 있습니다. 또한 $f$가 simple function이면 Step 2의 정의와 일치하는 것을 알 수 있습니다.

-![mt-05.png](../../../assets/img/posts/mt-05.png)
+![mt-05.png](../../../assets/img/posts/Mathematics/Measure%20Theory/mt-05.png)

 $f \geq 0$ 가 measurable이면 증가하는 measurable simple 함수열 $s_n$이 존재함을 지난 번에 보였습니다. 이 $s_n$에 대하여 적분값을 계산해보면

--- a/Theory/2023-03-25-convergence-theorems.md
+++ b/Theory/2023-03-25-convergence-theorems.md
@@ -8,7 +8,9 @@ title: "06. Convergence Theorems"
 date: "2023-03-25"
 github_title: "2023-03-25-convergence-theorems"
 image:
-  path: /assets/img/posts/mt-06.png
+  path: /assets/img/posts/Mathematics/Measure Theory/mt-06.png
+attachment:
+  folder: assets/img/posts/Mathematics/Measure Theory
 ---

 르벡 적분 이론에서 굉장히 자주 사용되는 수렴 정리에 대해 다루겠습니다. 이 정리들을 사용하면 굉장히 유용한 결과를 쉽게 얻을 수 있습니다.
@@ -17,7 +19,7 @@ image:

 먼저 단조 수렴 정리(monotone convergence theorem, MCT)입니다. 이 정리에서는 $f_n \geq 0$ 인 것이 매우 중요합니다.

-![mt-06.png](../../../assets/img/posts/mt-06.png)
+![mt-06.png](../../../assets/img/posts/Mathematics/Measure%20Theory/mt-06.png)

 **정리.** (단조 수렴 정리) $f_n: X \rightarrow[0, \infty]$ 가 measurable이고 모든 $x \in X$ 에 대하여 $f_n(x) \leq f_ {n+1}(x)$ 라 하자.

--- a/Theory/2023-04-07-dominated-convergence-theorem.md
+++ b/Theory/2023-04-07-dominated-convergence-theorem.md
@@ -8,7 +8,9 @@ title: "07. Dominated Convergence Theorem"
 date: "2023-04-07"
 github_title: "2023-04-07-dominated-convergence-theorem"
 image:
-  path: /assets/img/posts/mt-07.png
+  path: /assets/img/posts/Mathematics/Measure Theory/mt-07.png
+attachment:
+  folder: assets/img/posts/Mathematics/Measure Theory
 ---

 ## Almost Everywhere
@@ -147,7 +149,7 @@ $$[f] = \lbrace g \in \mathcal{L}^{1}(E, \mu) : f \sim g\rbrace.$$

 마지막 수렴정리를 소개하고 수렴정리와 관련된 내용을 마칩니다. 지배 수렴 정리(dominated convergence theorem, DCT)로 불립니다.

-![mt-07.png](../../../assets/img/posts/mt-07.png)
+![mt-07.png](../../../assets/img/posts/Mathematics/Measure%20Theory/mt-07.png)

 **정리.** (지배 수렴 정리) Measurable set $E$와 measurable function $f$에 대하여, $\lbrace f_n\rbrace$이 measurable function의 함수열이라 하자. $E$의 거의 모든 점 위에서 극한 $f(x) = \displaystyle\lim_ {n \rightarrow\infty} f_n(x)$ 가 $\overline{\mathbb{R}}$에 존재하고 (점별 수렴) $\lvert f_n \rvert \leq g \quad \mu$-a.e. on $E$ ($\forall n \geq 1$) 를 만족하는 $g \in \mathcal{L}^{1}(E, \mu)$ 가 존재하면,

@@ -188,5 +190,4 @@ $$2 \int_A g \,d{\mu} - \limsup_ {n \rightarrow\infty} \int_A \lvert f_n - f \rv
 이고, 가정에 의해 $\displaystyle 0 \leq \int_A g \,d{\mu} < \infty$ 이므로 $\displaystyle\limsup_ {n \rightarrow\infty} \int_A \lvert f_n - f \rvert \,d{\mu} = 0$ 이다.

 [^1]: 예를 들어, ‘$f(x)$가 연속이다’ 등.
-
 [^2]: Continuity of measure를 사용하기 위해서는 첫 번째 집합의 measure가 유한해야 한다.
--- a/Theory/2023-06-20-comparison-with-riemann-integral.md
+++ b/Theory/2023-06-20-comparison-with-riemann-integral.md
@@ -8,10 +8,12 @@ title: "08. Comparison with the Riemann Integral"
 date: "2023-06-20"
 github_title: "2023-06-20-comparison-with-riemann-integral"
 image:
-  path: /assets/img/posts/mt-08.png
+  path: /assets/img/posts/Mathematics/Measure Theory/mt-08.png
+attachment:
+  folder: assets/img/posts/Mathematics/Measure Theory
 ---

-![mt-08.png](../../../assets/img/posts/mt-08.png)
+![mt-08.png](../../../assets/img/posts/Mathematics/Measure%20Theory/mt-08.png)

 ## Comparison with the Riemann Integral

--- a/Theory/2023-07-31-Lp-functions.md
+++ b/Theory/2023-07-31-Lp-functions.md
@@ -8,10 +8,12 @@ title: "09. $\\mathcal{L}^p$ Functions"
 date: "2023-07-31"
 github_title: "2023-07-31-Lp-functions"
 image:
-  path: /assets/img/posts/mt-09.png
+  path: /assets/img/posts/Mathematics/Measure Theory/mt-09.png
+attachment:
+  folder: assets/img/posts/Mathematics/Measure Theory
 ---

-![mt-09.png](../../../assets/img/posts/mt-09.png){: .w-50}
+![mt-09.png](../../../assets/img/posts/Mathematics/Measure%20Theory/mt-09.png){: .w-50}

 ## Integration on Complex Valued Function

@@ -19,23 +21,23 @@ Let $(X, \mathscr{F}, \mu)$ be a measure space, and $E \in \mathscr{F}$.

 **정의.**

-1.  A complex valued function $f = u + iv$, (where $u, v$ are real functions) is measurable if $u$ and $v$ are both measurable.
+1. A complex valued function $f = u + iv$, (where $u, v$ are real functions) is measurable if $u$ and $v$ are both measurable.

-2.  For a complex function $f$,
+2. For a complex function $f$,

 	$$f \in \mathcal{L}^{1}(E, \mu) \iff  \int_E \left\lvert  f \right\rvert  \,d{\mu} < \infty \iff u, v \in \mathcal{L}^{1}(E, \mu).$$

-3.  If $f = u + iv \in \mathcal{L}^{1}(E, \mu)$, we define
+3. If $f = u + iv \in \mathcal{L}^{1}(E, \mu)$, we define

 	$$\int_E f \,d{\mu} = \int_E u \,d{\mu} + i\int_E v \,d{\mu}.$$

 **참고.**

-1.  Linearity also holds for complex valued functions. For $f_1, f_2 \in \mathcal{L}^{1}(\mu)$ and $\alpha \in \mathbb{C}$,
+1. Linearity also holds for complex valued functions. For $f_1, f_2 \in \mathcal{L}^{1}(\mu)$ and $\alpha \in \mathbb{C}$,

 	$$\int_E \left( f_1 + \alpha f_2 \right) \,d{\mu} = \int_E f_1 \,d{\mu} +  \alpha \int_E f_2 \,d{\mu}.$$

-2.  Choose $c \in \mathbb{C}$ and $\left\lvert  c \right\rvert  = 1$ such that $\displaystyle c \int_E f \,d{\mu} \geq 0$. This is possible since multiplying by $c$ is equivalent to a rotation.
+2. Choose $c \in \mathbb{C}$ and $\left\lvert  c \right\rvert  = 1$ such that $\displaystyle c \int_E f \,d{\mu} \geq 0$. This is possible since multiplying by $c$ is equivalent to a rotation.

 Now set $cf = u + vi$ where $u, v$ are real functions and the integral of $v$ over $E$ is $0$. Then,

@@ -109,9 +111,9 @@ We treat $[f]$ as an element in $\mathcal{L}^{p}(X, \mu)$, and write $f = [f]$.

 **참고.**

-1.  We write $\left\lVert f \right\rVert_p = 0 \iff f = [0] = 0$ in the sense that $f = 0$ $\mu$-a.e.
+1. We write $\left\lVert f \right\rVert_p = 0 \iff f = [0] = 0$ in the sense that $f = 0$ $\mu$-a.e.

-2.  Now $\lVert \cdot \rVert_p$ is a **norm** in $\mathcal{L}^{p}(X, \mu)$ so $d(f, g) = \left\lVert f - g \right\rVert_p$ is a **metric** in $\mathcal{L}^{p}(X, \mu)$.
+2. Now $\lVert \cdot \rVert_p$ is a **norm** in $\mathcal{L}^{p}(X, \mu)$ so $d(f, g) = \left\lVert f - g \right\rVert_p$ is a **metric** in $\mathcal{L}^{p}(X, \mu)$.

 ## Completeness of $\mathcal{L}^p$

@@ -119,9 +121,9 @@ Now we have a *function space*, so we are interested in its *completeness*.

 **정의.** (Convergence in $\mathcal{L}^p$) Let $f, f_n \in \mathcal{L}^{p}(\mu)$.

-1.  $f_n \rightarrow f$ in $\mathcal{L}^p(\mu) \iff \left\lVert f_n-f \right\rVert_p \rightarrow 0$ as $n \rightarrow\infty$.
+1. $f_n \rightarrow f$ in $\mathcal{L}^p(\mu) \iff \left\lVert f_n-f \right\rVert_p \rightarrow 0$ as $n \rightarrow\infty$.

-2.  $\left( f_n \right)_{n=1}^\infty$ is a Cauchy sequence in $\mathcal{L}^{p}(\mu)$ if and only if
+2. $\left( f_n \right)_{n=1}^\infty$ is a Cauchy sequence in $\mathcal{L}^{p}(\mu)$ if and only if

 > $\forall \epsilon > 0$, $\exists\,N > 0$ such that $n, m \geq N \implies \left\lVert f_n-f_m \right\rVert_p < \epsilon$.

@@ -206,4 +208,3 @@ $$\left\lVert f - \sum_{k=1}^{m} a_k g_n^k \right\rVert_p = \left\lVert \sum_{k=
 Next for $f \in \mathcal{L}^{p}$ and $f \geq 0$, there exist simple functions $f_n \geq 0$ such that $f_n \nearrow f$ in $\mathcal{L}^{p}$. Finally, any $f \in \mathcal{L}^{p}$ can be written as $f = f^+ - f^-$, which completes the proof.

 이러한 확장을 몇 번 해보면 굉장히 routine합니다. $\chi_F$ for closed $F$ $\rightarrow$ $\chi_A$ for measurable $A$ $\rightarrow$ measurable simple $f$ $\rightarrow$ $0\leq f \in \mathcal{L}^{p} \rightarrow$ $f \in \mathcal{L}^{p}$ 와 같은 순서로 확장합니다.
-