해당 포스팅은 "쿠버네티스 인 액션"을 공부하고 정리한 글입니다. 모든 내용은 해당 도서를 기준으로 합니다.
⬛ 7장 컨피그맵과 시크릿 : 애플리케이션 설정
◼️ 7.1 컨테이너화 된 애플리케이션 설정
일반적으로 컨테이너화된 애플리케이션이 어떻게 구성되는지
- 명령줄 인수로 애플리케이션에 필요한 설정을 넘겨주는 것으로 이후 설정할 옵션 목록이 커지면 설정을 파일에 저장하고 사용할 수 있음.
- 환경 변수 사용하여 애플리케이션이 특정 환경변수의 값을 찾도록 하는 것.
컨피그맵
- 설정 데이터를 저장하는 쿠버네티스 리소스
- 설정 데이터를 저장할지 여부에 관계없이 다음 방법을 통해 애플리케이션 구성 가능
- 컨테이너 명령줄 인수 전달
- 각 컨테이너를 위한 사용자 정의 환경변수 지정
- 특수한 유형의 볼륨을 통해 설정 파일을 컨테이너에 마운트
◼️ 7.2 컨테이너 명령줄 인자 전달
ENTRYPOINT와 CMD
Dockerfile에서 두 개의 지침은 다음 두 부분을 정의함
- ENTRYPOINT는 컨테이너가 시작될 때 호출될 명령어를 정의
- CMD는 ENTRYPOINT에 전달되는 인자를 정의
ENTRYPOINT 명령어로 실행하고 기본 인자를 정의하려는 경우에만 CM를 지정하는 게 올바른 방법임.
→ 아무런 인자도 지정하지 않고 이미지를 실행할 수 있음.
shell과 exec 형식 간의 차이점
- shell 형식 - ENTRYPOINT node app.js
- exec 형식 - ENTRYPOINT [”node”, “app.js”]
- 내부에서 정의된 명령을 shell로 호출하는지 여부 차이
shell 형식을 사용했을 때 컨테이너의 프로세스 목록
메인 프로세스는 node 프로세스가 아닌 shell 프로세스임.
노드 프로세스는 shell에서 시작됨.
쿠버네티스에서 컨테이너를 정의할 때
- ENTRYPOINT와 CMD 둘 다 재정의 할 수 있음
- 컨테이너 정의 안에 command와 args 속성을 지정함
◼️ 7.3 컨테이너의 환경변수 설정
- 컨테이너화된 애플리케이션은 종종 환경병수를 설정 옵션의 소스로 사용
- 파드의 각 컨테이너를 위한 환경변수 리스트를 지정할 수 있음
새 파드를 만들 때
- 환경변수를 컨테이너 정의에 포함해 스크립트에 전달할 수 있음
- 환경변수는 파드 레벨이 아닌 컨테이너 정의 안에 설정
변숫값에서 다른 환경변수 참조
- $(VAR) 구문을 사용해 이미 정의된 환경변수나 기타 기존 변수를 참조할 수도 있음
- 두번재 환경변수는 다음 예제와 같이 첫번째 변숫값을 포함할 수 있음
◼️ 7.4 컨피그맵으로 설정 분리
컨피그맵
- 쿠버네티스에서는 설정 옵션을 컨피그맵이라 부르는 별도 오브젝트로 분리할 수 있음
- 짧은 문자열에서 전체 설정 파일에 이르는 값을 가지는 키/값 쌍으로 구성된 맵
- 맵의 내용은 컨테이너의 환경변수 또는 볼륨 파일로 전달
- 컨피그맵 항목을 프로세스의 명령줄 인자로 전달 할 수도 있음
- 별도의 독립적인 오브젝트에 설정을 포함하면 각각 다른 환경에 관해 동일한 이름으로 컨피그맵에 관한 여러 매니페스트를 유지할 수 있음
- 파드는 컨피그맵을 이름으로 참조하기 때문에 모든 환경에서 동일한 파드 정의를 사용해 각 환경에서 서로 다른 설정을 사용할 수 있음
컨피그맵 생성
컨피그맵 항목을 환경변수로 컨테이너에 전달
파드에 존재하지 않는 컨피그맵 참조
- 존재하지 않는 컨피그맵을 지정하면 컨테이너는 시작하는데 실패함
- 누락된 컨피그맵을 생성하면 실패했던 컨테이터는 파드를 다시 만들지 않아도 시작됨
컨피그맵 항목을 명령줄 인자로 전달
컨피그맵 항목을 환경변수로 먼저 초기화하고 이 변수를 그림 7.7처럼 인자로 참조하도록 지정할 수 있음
컨피그맵 볼륨을 사용해 컨피그맵 항목을 파일로 노출
- 컨피그맵은 모든 설정 파일을 포함할 수 있음
- 이 파일들을 컨테이너에 노출시키려면 특수 볼륨 유형 중 하나인 컨피그맵 볼륨을 사용할 수 있음
- 컨피그맵 볼륨은 파일로 컨피그맵의 각 항목을 노출함
볼륨 안에 있는 컨피그맵 항목 사용
디렉터리 안에 다른 파일을 숨기지 않고 개별 컨피그맵 항목을 파일로 마운트
- 전체 볼륨을 마운트하는 대신 volumeMount에 subPath 속성으로 파일이나 디렉터리 하나를 볼륨에 마운트 할 수 있음
- myconfig.conf 파일을 포함하는 컨피그맵 볼륨을 가짐
- 이 파일을 /etc 디렉터리에 someconfig.conf 파일로 추가하려고 함
- subPath 속성으로 디렉터리에 있는 다른 파일에 영향을 주지 않고 마운트 할 수 있음
플리케이션을 재시작하지 않고 애플리케이션 설정 업데이트
- 환경 변수 또는 명령줄 인수를 설정 소스로 사용할 때의 단점은 프로세스가 실행되고 있는동안에 업데이트 할 수 없다는 것
- 컨피그맵을 사용해 볼륨으로 노출하면 파드를 다시 만들거나 컨테이너를 다시 시작할 필요 없이 설정을 업데이트 할 수 있음
파일이 한꺼번에 업데이트되는 방법 이해하기
- 애플리케이션이 설정 파일의 변경 사항을 자체적으로 감지하고 다시 로드할 경우에 모든 파일이 한 번에 동시에 업데이트되기 때문에 이런 일이 발생할 수 없음
- 쿠버네티스는 심볼릭 링크를 사용해 이를 수행함
이미 존재하는 디렉터리에 파일만 마운트했을 때 업데이트가 되지 않는 것 이해하기
- 컨피그맵 볼륨 업데이트와 관련이 있음
- 단일 파일을 컨테이너에 마운트한 경우 파일이 업데이트되지 않음
- 컨테이너의 가장 중요한 기능은 불변셩임
- 예전 파드는 계속해서 예전 설정을 사용함
- 애플리케이션이 설정을 자동으로 다시 읽는 기능을 가지고 있지 않으면 이미 존재하는 컨피그맵을 수정하는 것은 좋은 방법이 아님
◼️ 7.5 시크릿으로 민감한 데이터를 컨테이너에 전달
시크릿
- 설정 안에는 보안이 유지돼야 하는 자격증명과 개인 암호화 키와 같은 민감한 정보도 포함되어 있음
- 이러한 정보를 보관하고 배포하기 위해 쿠버네티스는 시크릿이라는 별도 오브젝트를 제공함
- 키-값 쌍을 가진 맵으로 컨피그맵과 매우 비슷함
- 환경 변수로 시크릿 항목을 컨테이너에 전달
- 시크릿 항목을 볼륨 파일로 노출
- 시크릿에 접근해야 하는 파드가 실행되고 있는 노드에만 개별 시크릿을 배포해 시크릿을 안전하게 유지함
- 노드 자체적으로 시크릿을 항상 메모리에만 저장되게 하고 물리 저장소에 기록되지 않도록 함
- 마스터 노드에는 시크릿을 암호화되지 않은 형식으로 저장하므로 마스터 노드를 보호하는 것이 필요함
기본 토큰 시크릿 소개
시크릿 생성
- 인증서와 개인 키를 만들어야 함
- 개인 키는 안전하게 유지해야 하므로 개인 키와 인증서를 시크릿에 넣어야 함
- 시크릿 항목의 내용은 Base64 인코딩 문자열로 표시되고 컨피그맵의 내용은 일반 텍스트로 표시 됨
stringData 필드 소개
- 쿠버네티스는 시크릿의 값을 stringData 필드로 설정할 수 있게 해줌
시크릿 볼륨을 메모리에 저장하는 이유
- tmpfs를 사용하는 이유는 민감한 데이터를 노출시킬 수도 있는 디스크에 저장하지 않기 위해서임
환경변수로 시크릿 항목 노출
- 오류 보고서에 환경변수를 기록하거나 시작하면서 로그에 환경변수를 남겨 의도치 않게 시크릿을 노출할 수 있음
해당 포스팅은 "쿠버네티스 인 액션"을 공부하고 정리한 글입니다. 모든 내용은 해당 도서를 기준으로 합니다.
⬛ 7장 컨피그맵과 시크릿 : 애플리케이션 설정
◼️ 7.1 컨테이너화 된 애플리케이션 설정
일반적으로 컨테이너화된 애플리케이션이 어떻게 구성되는지
- 명령줄 인수로 애플리케이션에 필요한 설정을 넘겨주는 것으로 이후 설정할 옵션 목록이 커지면 설정을 파일에 저장하고 사용할 수 있음.
- 환경 변수 사용하여 애플리케이션이 특정 환경변수의 값을 찾도록 하는 것.
컨피그맵
- 설정 데이터를 저장하는 쿠버네티스 리소스
- 설정 데이터를 저장할지 여부에 관계없이 다음 방법을 통해 애플리케이션 구성 가능
- 컨테이너 명령줄 인수 전달
- 각 컨테이너를 위한 사용자 정의 환경변수 지정
- 특수한 유형의 볼륨을 통해 설정 파일을 컨테이너에 마운트
◼️ 7.2 컨테이너 명령줄 인자 전달
ENTRYPOINT와 CMD
Dockerfile에서 두 개의 지침은 다음 두 부분을 정의함
- ENTRYPOINT는 컨테이너가 시작될 때 호출될 명령어를 정의
- CMD는 ENTRYPOINT에 전달되는 인자를 정의
ENTRYPOINT 명령어로 실행하고 기본 인자를 정의하려는 경우에만 CM를 지정하는 게 올바른 방법임.
→ 아무런 인자도 지정하지 않고 이미지를 실행할 수 있음.
shell과 exec 형식 간의 차이점
- shell 형식 - ENTRYPOINT node app.js
- exec 형식 - ENTRYPOINT [”node”, “app.js”]
- 내부에서 정의된 명령을 shell로 호출하는지 여부 차이
shell 형식을 사용했을 때 컨테이너의 프로세스 목록
메인 프로세스는 node 프로세스가 아닌 shell 프로세스임.
노드 프로세스는 shell에서 시작됨.
쿠버네티스에서 컨테이너를 정의할 때
- ENTRYPOINT와 CMD 둘 다 재정의 할 수 있음
- 컨테이너 정의 안에 command와 args 속성을 지정함
◼️ 7.3 컨테이너의 환경변수 설정
- 컨테이너화된 애플리케이션은 종종 환경병수를 설정 옵션의 소스로 사용
- 파드의 각 컨테이너를 위한 환경변수 리스트를 지정할 수 있음
새 파드를 만들 때
- 환경변수를 컨테이너 정의에 포함해 스크립트에 전달할 수 있음
- 환경변수는 파드 레벨이 아닌 컨테이너 정의 안에 설정
변숫값에서 다른 환경변수 참조
- $(VAR) 구문을 사용해 이미 정의된 환경변수나 기타 기존 변수를 참조할 수도 있음
- 두번재 환경변수는 다음 예제와 같이 첫번째 변숫값을 포함할 수 있음
◼️ 7.4 컨피그맵으로 설정 분리
컨피그맵
- 쿠버네티스에서는 설정 옵션을 컨피그맵이라 부르는 별도 오브젝트로 분리할 수 있음
- 짧은 문자열에서 전체 설정 파일에 이르는 값을 가지는 키/값 쌍으로 구성된 맵
- 맵의 내용은 컨테이너의 환경변수 또는 볼륨 파일로 전달
- 컨피그맵 항목을 프로세스의 명령줄 인자로 전달 할 수도 있음
- 별도의 독립적인 오브젝트에 설정을 포함하면 각각 다른 환경에 관해 동일한 이름으로 컨피그맵에 관한 여러 매니페스트를 유지할 수 있음
- 파드는 컨피그맵을 이름으로 참조하기 때문에 모든 환경에서 동일한 파드 정의를 사용해 각 환경에서 서로 다른 설정을 사용할 수 있음
컨피그맵 생성
컨피그맵 항목을 환경변수로 컨테이너에 전달
파드에 존재하지 않는 컨피그맵 참조
- 존재하지 않는 컨피그맵을 지정하면 컨테이너는 시작하는데 실패함
- 누락된 컨피그맵을 생성하면 실패했던 컨테이터는 파드를 다시 만들지 않아도 시작됨
컨피그맵 항목을 명령줄 인자로 전달
컨피그맵 항목을 환경변수로 먼저 초기화하고 이 변수를 그림 7.7처럼 인자로 참조하도록 지정할 수 있음
컨피그맵 볼륨을 사용해 컨피그맵 항목을 파일로 노출
- 컨피그맵은 모든 설정 파일을 포함할 수 있음
- 이 파일들을 컨테이너에 노출시키려면 특수 볼륨 유형 중 하나인 컨피그맵 볼륨을 사용할 수 있음
- 컨피그맵 볼륨은 파일로 컨피그맵의 각 항목을 노출함
볼륨 안에 있는 컨피그맵 항목 사용
디렉터리 안에 다른 파일을 숨기지 않고 개별 컨피그맵 항목을 파일로 마운트
- 전체 볼륨을 마운트하는 대신 volumeMount에 subPath 속성으로 파일이나 디렉터리 하나를 볼륨에 마운트 할 수 있음
- myconfig.conf 파일을 포함하는 컨피그맵 볼륨을 가짐
- 이 파일을 /etc 디렉터리에 someconfig.conf 파일로 추가하려고 함
- subPath 속성으로 디렉터리에 있는 다른 파일에 영향을 주지 않고 마운트 할 수 있음
플리케이션을 재시작하지 않고 애플리케이션 설정 업데이트
- 환경 변수 또는 명령줄 인수를 설정 소스로 사용할 때의 단점은 프로세스가 실행되고 있는동안에 업데이트 할 수 없다는 것
- 컨피그맵을 사용해 볼륨으로 노출하면 파드를 다시 만들거나 컨테이너를 다시 시작할 필요 없이 설정을 업데이트 할 수 있음
파일이 한꺼번에 업데이트되는 방법 이해하기
- 애플리케이션이 설정 파일의 변경 사항을 자체적으로 감지하고 다시 로드할 경우에 모든 파일이 한 번에 동시에 업데이트되기 때문에 이런 일이 발생할 수 없음
- 쿠버네티스는 심볼릭 링크를 사용해 이를 수행함
이미 존재하는 디렉터리에 파일만 마운트했을 때 업데이트가 되지 않는 것 이해하기
- 컨피그맵 볼륨 업데이트와 관련이 있음
- 단일 파일을 컨테이너에 마운트한 경우 파일이 업데이트되지 않음
- 컨테이너의 가장 중요한 기능은 불변셩임
- 예전 파드는 계속해서 예전 설정을 사용함
- 애플리케이션이 설정을 자동으로 다시 읽는 기능을 가지고 있지 않으면 이미 존재하는 컨피그맵을 수정하는 것은 좋은 방법이 아님
◼️ 7.5 시크릿으로 민감한 데이터를 컨테이너에 전달
시크릿
- 설정 안에는 보안이 유지돼야 하는 자격증명과 개인 암호화 키와 같은 민감한 정보도 포함되어 있음
- 이러한 정보를 보관하고 배포하기 위해 쿠버네티스는 시크릿이라는 별도 오브젝트를 제공함
- 키-값 쌍을 가진 맵으로 컨피그맵과 매우 비슷함
- 환경 변수로 시크릿 항목을 컨테이너에 전달
- 시크릿 항목을 볼륨 파일로 노출
- 시크릿에 접근해야 하는 파드가 실행되고 있는 노드에만 개별 시크릿을 배포해 시크릿을 안전하게 유지함
- 노드 자체적으로 시크릿을 항상 메모리에만 저장되게 하고 물리 저장소에 기록되지 않도록 함
- 마스터 노드에는 시크릿을 암호화되지 않은 형식으로 저장하므로 마스터 노드를 보호하는 것이 필요함
기본 토큰 시크릿 소개
시크릿 생성
- 인증서와 개인 키를 만들어야 함
- 개인 키는 안전하게 유지해야 하므로 개인 키와 인증서를 시크릿에 넣어야 함
- 시크릿 항목의 내용은 Base64 인코딩 문자열로 표시되고 컨피그맵의 내용은 일반 텍스트로 표시 됨
stringData 필드 소개
- 쿠버네티스는 시크릿의 값을 stringData 필드로 설정할 수 있게 해줌
시크릿 볼륨을 메모리에 저장하는 이유
- tmpfs를 사용하는 이유는 민감한 데이터를 노출시킬 수도 있는 디스크에 저장하지 않기 위해서임
환경변수로 시크릿 항목 노출
- 오류 보고서에 환경변수를 기록하거나 시작하면서 로그에 환경변수를 남겨 의도치 않게 시크릿을 노출할 수 있음
