Ch7. Configmaps and Secrets Ch8. Accessing pod metadata and other resources from applications

1. Ch7. Configmaps and
Secrets
Hongmin Park

2. Configure apps
1. Passing command-line args to containers
2. Setting custom env variables for each containers
3. Mounting conf files by a special type of volume

3. Passing command-line args
- 차이 : command is invoked inside a shell or not
- shell : 사용자와 커널 사이의 인터페이스를 감싸는 층. sh. GUI/CLI 형태.
- shell 을 타고 안타고 큰 차이가 있나?
- -> 큰 차이는 없으나 shell 을 굳이 탈필요 없으므로 exec form 권고.
ENTRYPOINT ["node", "app.js"] ENTRYPOINT node app.js

4. Setting environment var
- .yaml 내에 container level의 env절 추가
- Don’t forget that in each container, Kubernetes also automatically exposes environment variables for each
service in the same namespace. These environment variables are basically auto-injected configuration.
- 하드코딩의 단점 : 운영/개발 따로 작성해야함. 환경마다 pod def를 따로 작성
해야됨.

5. Configmap
- 변수를 따로 object로 관리.
- key:value 형식.
- 필요에 따라 container 의 환경변수로 등록하거나 volume 붙일수도.
- namespace 분리를 통해 아래처럼 같은 ConfigMap/pod 에서 환경구성 다르게
가능.

6. Configmap
- 변수를 따로 object로 관리.
- key:value 형식.
- 필요에 따라 container 의 환경변수로 등록하거나 volume 붙일수도.
- namespace 분리를 통해 동일 ConfigMap 이름, pod 에서 환경구성 다르게 가
능.
configmap 생성 방식의 조합
- multiple source 에서 생성 가능

7. Configmap - map to container
1. 컨테이너의 환경 변수로 등록
- valueFrom: / envFrom: 으로 변수 일부 or 변수 전체 container 에 매핑 가능.

8. Configmap - map to container
2. command-line argument 로 넘기기
- ConfigMap의 변수를 바로 불러 쓰는 것은 불가능
- yaml에서 변수 정의 후 사용

9. Configmap - map to container
3. 전체 파일을 configMap volume 으로 붙이기
- ConfigMap 의 각 요소를 각 파일로 생성함
- 컨테이너 내의 프로세스에서는 파일을 읽어 변수 가져옴.
컨테이너 내 설정파일이 mount 되어있는 것 확인 가능.
- 주의: 기존에 /etc/nginx/conf.d 경로에 있던 파일은 hide됨.
- subpath 로 mount 가능.

10. Configmap - update config
- Configmap resource 를 수정하면 연결된 container들도 자동 업데이트됨.
- 컨테이너에 mount된 Volume은 실제로 symbolic link 로 되어있고, Configmap
이 업데이트되면 symbolic link가 바뀜.
- Configmap 을 수정할 때: 수정 후 pod이 reload되지 않으면 수정본이 먹히지
않기 때문에, 수정 전에 생성된 pod과 수정 후에 생성된 pod 사이에 차이 발생
가능.

11. Secrets
- Secrets: Configmap 같은 resource
- key:value 구조
- container에 environment var 로 줄 수 있음.
- volume 으로 줄 수 있음
- Secret을 필요로 하는 pod을 띄우는 node에만 공개됨.
- memory에만 저장. 물리 disk에는 No.
- k8s v1.7에서부터는 master node(etcd)에도 encrypted.
- 사실 모든 pod 에는 Secret 볼륨이 있고, 모든 container 에 마운트 되어있음.

12. Secrets
- 1) ca.certs + 2) namespace + 3) token 으로 구성되어 있음.
- pod 과 k8s API 와의 secure 보장.
- 각 pod의 각 container 에 모두 mount 되어있
음.

13. Secrets
- Secrets의 값들은 base64 encoding 되어있다.
- plain-text 뿐만 아니라 binary value 들을 포함하기 위해 base64 encoding함.
- base64 encoding 은 binary data를 YAML/JSON으로 옮길 수 있도록 함. (?)
- stringData 라는 field 는 plain-text 가능(No base64)
- 실제로 컨테이너에 mount된 파일은 암호화 안되어있음.
암호화(YAML) vs 비암호화(container)

14. Configmap vs Secrets
- pod에 volume 으로 configmap, secret 생성 후
- 각 container에 volumeMounts 로 붙임.

15. Configmap vs Secrets
- 기억: Secret 은 in-memory 다!
- in-memory filesystem인 tmpfs 사용.
- -> 근데 무슨 의미? 어차피 컨테이너 죽으면 in-memory던 disk에 쓰던 어차피
결국 날아가는 것 아닌가?
- secret 도 configmap 처럼 환경변수로 노출시킬 수 있으나.. 안전해 보이진 않
는다

16. Ch8. Accessing pod metadata and
other resources from applications
Hongmin Park

17. What to learn ?
● Using the Downward API to pass information into containers
● Exploring the Kubernetes REST API
● Leaving authentication and server verification to kubectl proxy
● Accessing the API server from within a container
● Understanding the ambassador container pattern
● Using Kubernetes client libraries

18. k8s Downward API
- pod의 이름, IP, label, CPU 등
- pod 의 정보를 container안의 프로세스에서 사용해야 할 때에.
- 환경변수 or downwardAPI volume
- configMap/secret 은 넘길 정보를
- 알 때.
- downwardAPI는 동적 정보가 필요할때

19. 실습(을 따라해보려 하였으나..)
- 에러와 마주하고 마는데 ..
- downward pod를 생성하려고하는데

20. k8s API server
- downwardAPI 는 자기 pod에 대한 정보만 줌.
- API server 에 다이렉트로는 안되고, kubectl proxy 를 통해 날려야됨.

21. k8s API server
- pod 안에서 k8s API server 와의 통신?
- 1) pod 에서 통신할 API 서버의 주소 IP:port
*컨테이너 밖에서
*컨테이너 안에서
Q. 모든 컨테이너에 k8s 가 자동으로 env 뿌려줬었나?
-> each Service 에 env 설정됨.
Q. 방금은 pod 을 만든거였는데..
-> kubernetes 라는 Service 는 모든 pod에 뿌려지나
봄..

22. k8s API server
fail..-> DNS문제.. ?
Q. 모든 컨테이너에 k8s 가 자동으로 env 뿌려줬었나?
-> each Service 에 env 설정됨.
Q. 방금은 pod 을 만든거였는데..
-> kubernetes 라는 Service 는 모든 pod에 뿌려지나
봄..

23. k8s API server
- account 조치 취한 후 TOKEN/CURL_CA_BUNDLE 변수 다시 확인 후 성공
- API 서버는 https 와는 별개로 token 도 인증에 필요로 함.

24. Ambassador container
- container ---(https)---> API server (X)
- container ---(http)---> Ambassador container ---(https)---> API server (O)
-> 동일 pod 에 존재
- pod에 main, ambassador컨테이너 띄움
- main 컨테이너에 접속헤 localhost:8001 로 ambassador
container 호출
*동일 pod의 container -> 동일 namespace 이므로
localhost로 날림
- ambassador가 API 호출

25. Ambassador container
- Ambassador 컨테이너에 접속해보니 ..
- 아래와 같이 kubectl proxy 를 실행중
- pod에 main, ambassador컨테이너 띄움
- main 컨테이너에 접속헤 localhost:8001 로 ambassador
container 호출
*동일 pod의 container -> 동일 namespace 이므로
localhost로 날림

26. - ambassador container 같은 것 대신에
- https지원, 인증 처리해주는 클라이언트 라이브러리로 대체 가능
- Golang, python, java 등 다양한 언어에서 라이브러리 지원.
- 코드에서 바로 k8s API server를 call할 일이 있을 때에, 해당 언어에 맞는 라이
브러리를 선택해서 API call 가능.
- -> ambassador container 보다 편해보임. 관리 포인트가 주니까.
Client libraries to API server
- pod에 main, ambassador컨테이너 띄움
- main 컨테이너에 접속헤 localhost:8001 로 ambassador
container 호출
*동일 pod의 container -> 동일 namespace 이므로
localhost로 날림
[Java Client Library example]