ParanBlog.

Container Runtime은 컨테이너의 추가/삭제마다 Network plugin을 불러야 한다.Kubelet 서비스를 보면, ExecStart=/user/local/bin/kubelet \\... --network-plugin=cni \\ --cni-bin-dir=/opt/cni/bin \\ --cni-conf-dir=/etc/cni/net.d \\...처럼 되어 있다.주의쿠버 1.24 이전까지는 kubelet에서 cni-bin-dir과 network-plugin 파라미터를 통해 CNI 플러그인을 관리하는 것이 가능했으나, 이는 쿠버 1.24에서 삭제되었다!/opt/cni/bin에는 bridge, dhcp, flannel, host-local 등 CNI Network Plugin의 execut..

None네트워크가 없다. 외부로 통신 불가.Host호스트의 네트워크에 그대로 노출한다. 컨테이너 안에서 80을 열면 호스트의 IP로 80에 접근해서 내용을 볼 수 있다.두 개의 컨테이너가 같은 포트를 열 수는 없다.Bridge기본값으로 172.17.0.0/24의 브리지 네트워크가 생성되어 내부 private network 주소를 할당받는다.기본값으로 "bridge"라는 이름의 네트워크가 생성된다. docker network ls를 찍어 보면 Network 이름이 bridge로 되어 있으나, 실제로 호스트에서 생성되는 네트워크 이름은 docker0이다.Docker에서docker inspect 명령의 NetworkSettings 부분을 보면, 컨테이너의 네트워크 네임스페이스를 볼 수 있다.ip link 명령..

Network Namespace 개념은 리눅스 컨테이너에서 네트워크 분리를 위해 사용되는 기술이다.컨테이너는 Process Namespace로 격리되어 있어서, 컨테이너 위에서 돌아가는 프로세스만 볼 수 있다. 컨테이너 위에서 ps aux를 찍어 보면 CMD로 구동되는 프로세스의 PID가 1임을 볼 수 있다.하지만 호스트에서 ps aux를 찍어 보면, 해당 프로세스의 PID가 전혀 다른 값으로 들어가 있는 것을 볼 수 있다.즉 같은 프로세스가 컨테이너 내부와 외부에서 전혀 다른 PID를 가지고 있는 것이다.네트워크 네임스페이스도 비슷하다. 호스트에는 Routing 및 ARP Table이 존재한다.하지만 컨테이너 생성 시에는 네트워크 네임스페이스가 생성되며, 컨테이너 내부에서는 호스트의 네트워크 관련 정보..

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클러스터 기능에 직접적으..