CKA-8일차

📍 CKA 8일차
📍 Udemy-Certified Kubernetes Administrator (CKA) with Practice Tests 94-104

---

95. Commands

도커에서 컨테이너는 컨테이너 내부의 프로세스가 살아있어야 Running 상태가 된다.
컨테이너 안의 웹 서비스가 멈추거나 충돌하면 컨테이너는 종료된다.

컨테이너에서 실행되는 프로세스는 Dockerfile에 의해 정의된다.
Dockerfile의 CMD는 컨테이너 안에서 실행될 명령이다.

컨테이너 시작 명령을 어떻게 지정할까?

첫번째 방법은 docker run 명령어에 COMMAND를 추가하는 것이다.
그럼 이미지에 지정된 기본 명령을 재정의한다.
docker run ubuntu sleep 5를 실행하면 컨테이너가 작동할 때 sleep을 5초 동안 실행하고 종료된다.

두 번째 방법은 CMD를 추가한 Dockerfile을 작성해서 이미지를 빌드하는 것이다.
일시적으로 명령을 실행하는 앞의 방법과 다르게 컨테이너가 영구적으로 명령을 실행하도록 할 수 있다.

명령을 지정하는 방법은 셸 양식, JSON이 있다.
JSON 배열 포맷에서 명령을 지정할 때 배열의 첫 번째 요소가 실행 가능해야 한다.
또한 명령과 매개 변수를 별도로 지정해야 한다.

CMD는 docker run 명령의 [COMMAND] 옵션에 따라 CMD의 매개변수가 완전히 바뀐다.
반면에, ENTRYPOINT의 경우 전달받은 매개변수를 추가해서 명령을 실행한다.
만약, 매개변수를 전달 받지 못하면 'sleep' 명령이 실행되어 누락된 명령문이라는 오류가 발생한다.

매개변수의 기본값을 설정하기 위해서 ENTRYPOINT와 CMD를 둘 다 사용하면 된다.
이 경우, 매개변수를 지정하지 않았다면 ENTRYPOINT 명령어에 CMD 명령이 추가된다.
만약 매개변수가 지정되었으면 CMD 명령은 무효화된다.
이러한 경우에는 ENTRYPOINT와 CMD를 항상 JSON 포맷으로 지정해야 한다.

마지막으로 ENTRYPOINT를 수정하고 싶다면 '--entrypoint' 옵션을 사용해 재정의하면 된다.

---

96. Commands and Arguments

도커 실행 명령에 추가되는 모든 것은 파드 정의 파일의 args 속성으로 가지게 된다.
파드 정의 파일의 args 옵션을 통해 Dockerfile의 CMD를 재정의할 수 있다.

Dockerfile의 ENTRYPOINT를 변경해야 한다면 파드 정의 파일의 command 옵션을 사용하면 된다.

즉, 파드 정의 파일의 command 영역은 Dockerfile의 ENTRYPOINT 영역을 덮어쓰고
args 영역은 Dockerfile의 CMD 영역을 덮어쓴다.

---

98. Solution - Commands and Arguments

파드 정의 파일에서 args와 command를 명시할 수 있다.

args와 command는 다음과 같이 두가지
형식으로 명시된다.

아래의 경우, '--color green'이 컨테이너에서 실행된다.

아래의 경우, 'python app.py --color pink'가 컨테이너에서 실행된다.

kubectl run 명령어를 실행할 때 다음 옵션들을 사용해서 args와 command를 넘겨줄 수 있다.
kubectl 옵션과 컨테이너 안에서 실행되는 응용 프로그램 옵션을 구분하기 위해 '--'가 사용된다.

---

99. Configure Environment Variables in Applications

파드 정의 파일에서 env 필드를 사용하여 환경변수를 설정할 수 있다.

키-값 포맷을 사용하는 방법 이외에도 컨피그맵과 시크릿키를 사용해서 env를 지정할 수 있다.

---

100. Configuring ConfigMaps in Application

컨피그 맵은 중앙에서 키 값 쌍의 데이터를 한번에 관리하기 위해 사용된다.
파드 정의 파일의 env 필드에 컨피그맵을 삽입하여 컨피그맵의 키 값 쌍이 환경 변수로 사용될 수 있게 한다.

컨피그 맵 구성에는 두 단계가 있다.
1. Create ConfigMap
2. Inject into Pod

다른 쿠버네티스 개체들과 마찬가지로 컨피그맵을 만드는 방법은 두 가지가 있다.
명령적인 방법은 kubectl create configmap 명령어를 사용하는 것이고
선언적인 방법은 configmap 정의 파일을 작성하고 kubectl create -f 명령어를 실행하는 것이다.

kubectl create configmap 명령어를 사용할 때 키 값 데이터를 명시하기 위해 '--from-literal' 옵션을 사용할 수 있다. 여러 개의 키 값을 명시하기 위해서는 '--from-literal' 옵션을 여러번 사용해야 한다.
'--from-file' 옵션을 사용하여 파을을 통해 필요한 키 값 데이터를 한번에 전달할 수도 있다.

configmap 정의 파일을 통해 다음과 같이 configmap을 생성할 수 있다.

다양한 목적을 위해 같은 방식으로 필요한만큼 configmap을 생성할 수 있다.
그렇기 때문에 configmap에 이름을 적절히 붙이는 것이 중요하다.

컨피그맵을 통해 환경 변수를 전달하기 위해서는 파드 정의 파일의 'envFrom' 필드에 컨피그맵 이름을 명시하면 된다.

파드 정의 파일에서 configmap을 사용하는 경우는 다음 세 가지이다.
env, single env, volume으로 사용될 수 있다.

---

102. Solution - Environment Variables

configmap으로 환경변수 설정하기
❗주의할 점! 띄어쓰기를 주의하자!!

---

103. Configure Secrets in Applications

ConfigMap은 일반 텍스트 형식으로 구성 데이터를 저장하기 때문에 암호를 저장하기에는 부적절하다.
암호를 저장하기 위해 Secret이 사용된다.
Secret은 비밀번호 등 민감한 정보를 저장하는 데 사용된다.
인코딩된 형식으로 저장된다는 점만 빼면 ConfigMap과 비슷하다.

Secret 역시 두 가지 방법으로 만들 수 있다.

먼저 명령적인 방법은 '--from-literal'옵션을 통해 키 값 쌍을 지정할 수 있다.
비밀이 너무 많으면 '--from-file' 옵션을 이용해 파일로 키 값 쌍을 한번에 지정할 수 있다.

다음으로 선언적인 방법에서는 시크릿 정의 파일을 먼저 작성하고 kubectl apply -f 명령어를 통해 시크릿을 생성한다.
여기서 주의할 점은 데이터를 인코딩된 포맷으로 저장해야 한다는 것이다.

일반 형식에서 인코딩 된 형식으로 데이터를 변환하기 위해 다음과 같은 명령어를 실행하면 된다.

Secret을 확인하기 위해 다음 명령어들을 사용할 수 있다.
Secret의 데이터를 확인하기 위해서는 kubectl get secret 시크릿명 -o yaml 명령어를 사용하면 된다.

인코딩된 값을 해독하기 위해서 '--decode' 옵션을 사용하면 된다.

파드의 env로 시크릿을 사용할 수 있다. 파드 정의 파일에 환경 변수를 삽입하려면 envFrom이라는 필드를 사용하면 된다.

파드에 시크릿을 주입하는 다른 방법도 있다.
단일 환경 변수로 넣을 수 있고 볼륨으로 넣을 수도 있다.

파드의 볼륨으로 시크릿을 사용할 경우, 시크릿의 각각의 특성은 파일로 생성된다.
파일에는 암호 값이 담겨 있다.
이 경우에는 3개의 암호가 3개의 파일에 담겨 있다.

Secret을 다룰 때는 주의할 점이 있다.
우선, Secret은 암호화되어 있지 않다. 그래서 누구든 Secret 정의 파일을 볼 수 있고 Secret 개체를 얻을 수 있다. 그리고 기밀 데이터를 볼 수 있다.
따라서 주의해야 하며 RBAC(Role Based Access Control, 역할 기반 접근 제어)나 제 3자의 암호 공급자를 고려하는 것이 좋다.

---

104. A note about Secrets

Secret은 base64 형식으로 데이터를 인코딩한다. base64로 인코딩된 암호를 가진 사람은 누구나 암호를 디코딩할 수 있다. 따라서 Secret은 그다지 안전하지 않은 것으로 간주될 수 있다.
Secret은 암호 및 기타 중요한 데이터가 실수로 노출될 위험이 줄어들기 때문에 일반 텍스트로 저장하는 것보다 안전하다.
'Secret 정의 파일을 소스 코드 레포지토리에 올리지 않는다', 'ETCD에 암호화되어 저장되도록 ETCD에 저장될 때 Secret에 대한 암호화를 가능하게 한다' 등의 관행은 Secret이 더욱 안전하도록 만들어 준다.

또한 쿠버네티스는 Secret을 안전하게 처리하기 위해

• Secret은 해당 노드의 파드에 필요한 경우에만 노드로 전송된다.
• kubelet은 Secret이 디스크 저장소에 기록되지 않도록 Secret을 tmpfs에 저장한다.
• Secret에 의존하는 Pod가 삭제되면 kubelet은 Secret 데이터의 로컬 복사본도 삭제한다.

그러나 Helm Secrets, HashiCorp Valut와 같은 도구를 사용하는 것과 같이 Kubernetes의 비밀번호와 같은 민감한 데이터를 처리하는 다른 더 좋은 방법이 있다.