Kubernetes - ConfigMap, Secret, Volume
ConfigMap
우리는 어플리케이션 yaml파일에서 db host라던지 패스워드 등을 적곤한다.
그런데 이러한 환경변수 값을 deployment에서 적을 수 있다.
그런데 아래와 같이 적는방법도 있다.
env:
- name: MY_ACCOUNT
value: hello
- name: MY_PASSWORD
value: pwd1234
그러나 이러한 설정값을 디플로이먼트에 적는다는것은 관리하기가 어려워진다 설정값 변경만해도 디플로이먼트를 다시 배포해야한다.
각각의 역할을 가지고 있는 것처럼 환경 변수를 관리하는 역할을 가진 오브젝트가 따로 존재하는것이다. 이게 바로 컨피그 맵이다.
더해서 별도의 파일로 분리를 해서 관리함으로써 유지보수가 편리해지고 개발, 테스트, 프로덕션과 같은 환경 분리가 편해진다.
시크릿
시크릿은 ConfigMap과 비슷하게 환경 변수를 분리해서 관리하는 오브젝트입니다.
차이점은 보안적으로 중요한 값을 관리하기 위한 오브젝트입니다.
그런데 제가 적는것은 파일이고 다를게 없을거 같아서 알아봤습니다.
그 결과 컨피그맵은 평문으로 저장되나 시크릿은 Base64로 인코딩되어 저장된다는 점이 달랐습니다
- 시크릿(Secret)은 기본적으로 Base64로 인코딩되어 저장되며, 쿠버네티스 클러스터 내에서는 보안적인 스토리지에 저장됩니다.
- 쿠버네티스 버전 1.13 이상에서는 ETCD에 저장된 시크릿 데이터를 암호화하는 옵션도 지원합니다.
볼륨
파드가 가진 문제점은 프로그램에 기능이 추가되면 쿠버네티스에서는 기존 파드에서 변경된 부분을 수정하지 않고, 새로운 파드를 만들어 통째로 갈아끼우는 방식으로 교체를 합니다. 그래서 mysql파드면 문제가 됩니다. 저장되었던 데이터도 같이 삭제되어 버리기때문입니다.
그래서 볼륨을 사용합니다
쿠버네티스의 볼륨 종류
- 로컬 볼륨 : 파드 내부의 공간 일부를 볼륨으로 활용하는 방식 - 파드가 삭제되는 즉시 데이터도 같이 삭제됩니다 잘 사용하지 않습니다
- 퍼시스턴스 볼륨 : 파드 외부의 공간 일부를 볼륨으로 사용하는 방식입니다. 이 방식은 삭제되는 것과 상관없이 영구적으로 사용할 수 있다는 장점이 있어, 현업에서 많이사용합니다
왜 쿠버네티스에서는 퍼시스턴스 볼륨이라고 부르는지 일반볼륨과 퍼시스턴스 볼륨은 다르다
일반볼륨은 주로 파드에서 관리되는 로컬볼륨을 부르는거 같다.
mysql의 서비스를 노드포트에서 클러스터ip로 바꿨는데 스프링부트랑 mysql연결중이었는데 스프링부트 파드는 왜 다시 실행시켜야해? mysql서비스만 재 실행시키면되는거아닌가
- DNS캐싱 문제 : MySQL 서비스가 NodePort에서 ClusterIP로 변경되면, 서비스의 엔드포인트가 변경되더라도 스프링 부트 애플리케이션은 이전의 캐싱된 DNS 정보를 사용하려고 시도합니다.결과적으로, 새 MySQL 서비스 엔드포인트에 접근하지 못해 연결이 실패할 수 있습니다.
- 커넥션 풀(Connection Pool) 문제 : 스프링 부트 애플리케이션이 MySQL과 연결하기 위해 DB 커넥션 풀(HikariCP 등)을 사용한다면, 기존 커넥션 풀에 저장된 연결 정보가 변경된 서비스 엔드포인트를 반영하지 못합니다. MySQL 서비스가 ClusterIP로 변경되면 이전의 커넥션이 유효하지 않게 됩니다. 즉 이전에 만들어두었던 커넥션으로 할려고 하다보니 문제
포트포워딩에 대한 잘못된 지식
포트포워딩은 내부로컬과 컨테이너나 다른곳을 포트끼리 연결하려는것인것을 몰랐다kubectl port-forward pod/<pod-name> <local-port>:<container-port>
을 쓰면 나는 local-port부분에 다른 호스트:포트 이렇게 해도 연결되는줄 알았다. 몰랐던것에 충격이었다. 주로 로컬을 말한거였고 회사에서는 주로 베스천서버랑 디비랑 포트포워딩(혹은 허용해두고)을 해두고 제 로컬이랑 베스천서버랑 포트포워딩 해서 사용했다.
다시하면 포트포워딩은 로컬이랑 다른 포트를 연결하는 것이다.
그래서 db같은경우는 노드포트보다 clusterIp로 해두고 개발환경이나 디버그나 디비관리를 하려면 포트포워딩을 통해 해결한다