ParanBlog.

Persistent Volumes (PV)Persistent Volume은 Storage Volume들의 클러스터 단위 pool이다. 클러스터의 사용자는 이 풀에서 스토리지를 선택하여 사용할 수 있다.apiVersion: v1kind: PersistentVolumemetadata: name: pv-vol1spec: accessModes: - ReadWriteOnce # ReadOnlyMany | ReadWriteOnce | ReadWriteMany capacity: storage: 1Gi hostPath: # 이 옵션을 Production에서 실제로 사용해서는 안됨 path: /tmp/data awsElasticBlockStore: # 혹은 외부 Storage Provider 사용 ..

Storage In Docker기본적으로 Docker는 /var/lib/docker 하위에 모든 데이터를 보관한다aufscontainersimagevolumesDocker (OCI) Image는 Layered Architecture로 되어 있다.Dockerfile의 각 line은 기존 이미지 위에 새로운 layer를 생성한다.FROM UbuntuRUN apt-get update && apt-get -y install pythonRUN pip install flask flask-mysqlCOPY . /opt/source-codeENTRYPOINT FLASK_APP=/opt/source-code/app.py flask runLayer5: 엔트리포인트 변경 (0B)Layer4: 복사된 소스코드 (229B)La..

Kubernetes Network Security여러 노드로 구성된 클러스터가 있다고 하자.이 클러스터에는 노드, 서비스, Pod 등등이 존재한다.그리고 이 노드, 서비스, Pod에는 모두 IP가 존재한다.쿠버에서는, (어떻게 구현을 했든지 상관없지만 아무튼) 같은 클러스터 내의 Pod들이 별도의 설정 없이도 서로 통신을 할 수 있어야 한다는 조건이 있다.예를 들어, 클러스터 전체가 VPN에 물려 있을 수도 있다. 이 경우 IP와 Pod/Service Name을 통해 서로에게 접근할 수 있을 것이다.기본적으로, 쿠버에서는, 클러스터 내부 Pod 간의 통신은 전부 허용 처리하는 것으로 되어 있다.예를 들어 웹서버 Pod, API서버 Pod, DB Pod으로 구성된 애플리케이션에 대해 생각해보자.Servic..

Docker(OCI) 컨테이너에서, 기본적으로 이미지 파일명 컨벤션은 image: domain.name/username/imagename:version이다.만약 image:nginx라고 간단하게 적었다면, 이것은 image: docker.io/library/nginx:latest로 해석된다.library는 Docker의 기본 사용자명이다.로그인을 해야 쓸 수 있는 Private Registry가 존재한다.대부분의 클라우드 프로바이더에서는 Private Registry 서비스를 제공한다.docker.io, gchr.io같은 퍼블릭 레지스트리에도 로그인해야 사용할 수 있는 Private Repo들이 존재한다.하지만 Kubernetes에서 어떻게 프라이빗 레지스트리에 로그인을 할 수 있는가?docker-reg..

쿠버에는 2가지 종류의 account가 존재한다.User - 사람이 사용admin, developer, etc.Service - 봇이 사용Prometheus같은 모니터링 프로그램 (쿠버 API를 통해 통계 생성), Jenkins같은 CI/CD 툴 (클러스터에 디플로이)Service Account 생성하기예를 들어 쿠버 상태 대시보드같은 걸 만든다고 하자. 그럼 당연히 쿠버 API에 접속해서 정보를 받아올 수 있어야 한다. 이를 위해 Service Account가 필요하다.kubectl create serviceaccount account-nameServiceAccount가 생성되면 자동으로 토큰을 생성한다*. 이 토큰을 이용하여 외부 애플리케이션이 Kubernetes API에 Authenticate할 수..

Authentication and AuthorizationAuthentication은 특정 사용자가 어떤 클러스터에 접근할 수 있는지 없는지를 결정Authorisation은 특정 사용자가 그 클러스터에서 뭘 할 수 있는지를 결정특정 사용자에 대해 모든 관리 권한을 다 주고 싶지 않을 수 있다노드를 삭제한다든지, 네트워크를 박살낸다든지 하는 위험한 짓은 하지 말고, Pod deployment 정도는 하게 할 수 있다.특정 봇에 대해서는 모니터링에 필요한 최소 권한만 주고자 할 수 있다.여러 클러스터를 공유하면서 네임스페이스로 논리적 분리한 환경에서는, 관리자가 할당된 네임스페이스에 대해서만 관리 가능하게 권한을 짜고자 할 수 있다.Authorisation의 메커니즘Node based예를 들어, kubele..

kubectl get pods 명령어같은 것들은 뒤에서는 kube-apiserver에 6443번 포트, TLS로 붙어서 정보를 받아온다.즉 kubectl은 뒤에서 GET /api/v1/pods HTTP/1.1 요청을 보내고, JSON으로 데이터가 반환되며, 이것을 예쁘게 가공해서 출력하는것이다.kubectl version도 마찬가지다. GET /version HTTP/1.1을 보낼것이다.(실제로는 HTTP 1.1은 아닐 수도 있겠지만, 아무튼)엔드포인트이 때 엔드포인트를 잘 보자./api/api/v1/pods, .../version/metrics/healthz/apis/logs이렇게 쿠버 API는 역할별로 그룹이 나누어져 있는데, 이것이 API Group이다. /api와 /apis클러스터 기능에 직접적으..

기본적으로 쿠버 컴포넌트 간의 통신은 모두 TLS Client Certificate를 요구한다. curl로 직접 API에 엑세스한다면,curl https://controlplane:6443/api/v1/pods --key admin.key --cert admin.crt --cacert ca.crt 같은 식으로 인증서를 제공해야 한다.kubectl에서도 마찬가지이다. 실제로kubectl get pods --server controlplane --client-key admin.key --client-certificate admin.crt --certificate-authority ca.crt같은 식으로, 파라미터를 통해 적절한 인증서를 공급할 수 있다.물론 이 파라미터를 다 치고 있는 것은 몹시 귀찮은 일이..

인증서 문제쿠버에서 인증서 관련 문제를 해결하려면 일단 해당 쿠버 클러스터가 어떻게 디플로이되었는지를 알아야 한다.예를 들어 kubeadm을 사용하여 올렸다면 상당 부분을 알아서 해준다kubeadm은 쿠버의 컴포넌트들을 Static Pods으로 올려준다.예를 들어 kube-apiserver는 /etc/kubernetes/manifests/kube-apsierver.yaml에 Pod Specification이 있고, 이 파일의 spec.containers.command 하위의 파라미터들을 통해, kube-apiserver의 인증서들의 존재를 알 수 있다.각 인증서 파일에 대해 openssl x509 -in /path/to/cert.crt -text 명령어로 Readable text 형태의 인증서를 볼 수 ..

쿠버에는 기본적으로 (관리자, 개발자 같은) 사용자라는 개념이 없다. kubectl create user user-name 같은 식으로 사용자를 생성하는 것은 당연히 불가능다만, 사람이 아닌 entity를 위한 Service Account라는 개념은 존재한다.하지만 kube-apiserver에 들어오는 API 콜 (kubectl이든 HTTP API endpoint를 통한 직접 접근이든) 을 무조건 다 받아주면 안되는 것은 자명하다. 어떻게든 user authentication을 거친 뒤에 리퀘를 받아줘야 하는 것이다.Kubernetes 1.19까지는 Client Certificate를 사용하지 않고 인증하는 방식들이 있었다비밀번호,사용자이름,사용자ID[,그룹] 형식의 CSV파일을 넣은 뒤, 요청 시 ID..