Winter Breeze

buffers와 cached 영역커널은 디스크로부터 데이터를 읽거나 사용자의 데이터를 디스크에 저장한다. 하지만 디스크는 매우 느리고 I/O에 상당한 시간이 소요되기 때문에 커널은 디스크에 대한 요청을 빠르게 하기 위해 메모리의 일부를 디스크 요청에 대한 캐싱 영역으로 할당한다. 이때 커널이 디스크 캐싱을 위해 할당한 영역을 buffers와 cached라고 부른다.커널이 읽어야 할 데이터가 파일의 내용이라면 커널은 bio 구조체를 생성하고 해당 구조체에 Page Cache 용도로 할당한 메모리 영역을 연결해준다. bio 구조체는 디바이스 드라이버와 통신하여 디스크로부터 데이터를 읽어 Page Cache에 파일의 내용을 채운다. super_block, inode_block처럼 파일의 내용이 아닌 파일 시스..

NodePortNodePort는 가장 기본적인 외부 노출 방식으로, 각 노드의 특정 포트를 통해 서비스를 외부에 노출한다.특징Kubernetes 노드의 IP와 특정 포트를 사용하여 외부에서 접근기본적으로 30000~32767 범위의 포트를 사용클러스터의 모든 노드에서 해당 포트로 서비스에 접근할 수 있다장점설정이 간단하고, 클러스터 외부에서 즉시 접근 가능추가적인 리소스 필요 없이 노드 IP로 접근 가능단점포트 범위가 제한적이며, 노드의 IP 주소를 알아야 합니다노드가 다운되면 해당 노드의 서비스에 접근 불가apiVersion: v1 kind: Service metadata: name: my-service spec: type: NodePort ports: ..

Overview쿠버네티스 환경에서의 보안이란 쿠버네티스 클러스터의 안정성과 보안성을 유지하는 것을 의미한다. 쿠버네티스는 클러스터의 보안을 위해 많은 기능을 제공하지만, 이번 포스팅에서는 CKA 자격증 준비를 위해 공부했던 세 가지 기능에 대한 소개를 하려고 한다.Network PolicyRole-Based Access ControlSecretNetwork Policy쿠버네티스의 통신 정책은 기본적으로 모든 Pod 간 통신을 허용한다. 이는 Pod 간 통신을 원활하게 해주지만, 원치 않는 통신에 Pod를 노출시킬 수 있다는 위험 또한 존재한다. 외부의 위협으로부터 Pod를 보호하기 위해 사용되는 쿠버네티스 보안 기능이 바로 네트워크 정책(Network Policy)이다. 네트워크 정책은 Pod 간 통신 ..

OverviewKubernetes 환경에서 이루어지는 네트워킹은 크게 4가지로 분류할 수 있다.서로 결합된 컨테이너와 컨테이너 간의 통신Pod와 Pod 간의 통신Pod와 Service 간의 통신외부와 Service 간의 통신서로 결합된 컨테이너와 컨테이너 간의 통신Docker 환경에서 생성된 컨테이너의 기본적인 네트워크 동작 구조를 그림으로 표현하면 아래와 같다.Docker에서는 기본적으로 같은 노드 내의 컨테이너끼리의 통신은 위 그림과 같이 docker0라는 가상 네트워크 인터페이스를 통해 가능하다. 각 컨테이너는 veth라는 가상 네트워크 인터페이스를 고유하게 가지며 따라서 각각의 veth IP 주소 값으로 통신할 수 있다. 하지만 두 컨테이너가 동일한 veth에 할당되는 경우도 존재한다.위 그림에서..

사용하던 서버의 리소스들을 Docker-Compose에서 Kubernetes를 사용하는 방식으로 마이그레이션을 진행하는 과정에서 Reverse Proxy 겸, LoadBalancer로 사용했던 Traefik 또한 Kubernetes Cluster로 옮겨야 했다. 마이그레이션을 진행하는 것을 계기로 겸사겸사 Kubernetes의 Ingress Controller로 사용되는 Traefik에 외부 접속이 가능하도록 External-IP를 할당해주는 방법과 Letsencrypt의 acme를 사용하여 HTTPS 인증서 사용이 가능하도록 하는 방법에 대한 포스팅을 적어보려고 한다. Traefik에 대한 대략적인 내용은 아래의 포스팅을 참조하자Traefik 이란?사전 준비 사항1. 외부 접속이 가능한 공인 DNS 필..

k8s Storage컨테이너 환경에서는 별도 설정을 하지 않으면 데이터는 호스트 노드의 임시 디스크에 보관된다. 컨테이너를 삭제하면 임시 디스크에 있는 데이터는 저장되지 않고 컨테이너와 함께 삭제된다. 이러한 문제를 쿠버네티스에서는 Pod와 데이터를 분리해서 영구 볼륨이라는 별도의 추상화된 리소스로 해결한다.쿠버네티스 볼륨을 구성하는 주요 리소스로 Persistent Volume (영구볼륨), PVC (Persistent VolumeClaim, 영구볼륨 요청자), Storage Class가 있다. 클러스터 관리자와 사용자(개발자)의 역할에 따라 쿠버네티스 볼륨에 관련된 작업이 서로 다르다. 클러스터 관리자는 클라우드 서비스 제공업자, 상용 혹은 오픈소스 솔루션 중에서 원하는 성능과 기능을 제공하는 스토리..

OSI 7 Layer User Mode 레벨에서의 OSI 7계층은 각각 Application Layer, Presentation Layer, Session Layer가 존재한다. User Mode 레벨에서의 계층의 전송 단위는 Data로 표현되며, 호스트(PC 혹은 노트북)가 주요 장비라고 볼 수 있다.Application Layer사용자와 가장 밀접한 계층으로 인터페이스 역할응용 프로세스 간의 정보 교환을 담당ProtocolHTTPFTPPresentation Layer데이터 형식을 설정한다송신자에게서 온 데이터를 해석하기 위한 Application Layer 데이터 부호화수신자 측에서 데이터의 압축을 풀수 있는 방식으로 데이터 압축데이터의 암호화 및 복호화ProtocolJPEGMPEGSession La..

Runtime Reconfigurationetcd 클러스터가 동작 중일 때, etcd 서버를 추가/삭제하는 것을 런타임 재구성이라고 한다.Member Add3개의 서버로 구성된 etcd 클러스터의 lastIndex가 10101이라고 가정해보자. etcd에는 Snapshot 이라는 개념이 있는데, etcd 서버가 현재까지 받아들인 모든 log를 Entry에서만 관리하는 것이 아니라 파일 시스템에 백업해두는 것을 의미한다. Snapshot 실행 빈도는 etcd 클러스터를 생성하면서 옵션으로 설정할 수 있고, 디폴트 값은 100,000이다. 이러한 상황에서 4번째 서버를 추가하는 요청이 발생했다고 가정해보자. etcd는 이러한 구성의 변경을 log append와 동일한 메커니즘으로 처리한다. Leader는 사..

etcd쿠버네티스는 기반 스토리지(backing storage)로 etcd를 사용하고 있고, 모든 데이터가 etcd에 보관된다. 예를 들어, 쿠버네티스 클러스터에 노드가 몇 개 있고, 어떤 Pod가 어떤 노드에서 동작하고 있는지 등이 etcd에 기록된다. etcd는 위와 이러한 정보를 key-value 형태로 저장한다. 만약 etcd가 다운되게 되면 쿠버네티스 클러스터는 제대로 동작하지 못하게 되기 때문에 높은 신뢰성을 제공해야 한다. etcd는 Replicated State Machine(RSM)이다. RSM은 서버들을 복사하고 복제된 서버와 클라이언트 간의 상호적용을 조율하는 것으로 장애 허용 서비스를 구현하는 일반적인 방법이다. RSM은 여러 노드에 동일한 상태 머신(State Machine)을 복..

PodK8s의 Pod는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다. 하나 이상의 컨테이너의 그룹이며, 이 그룹은 스토리지 및 네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고, 함께 스케줄되며, 공유 콘텍스트에서 실행된다.ReplicaSetyaml 파일 혹은 kubectl run 명령어를 통해 Pod를 생성할 수 있다. 하지만 Pod만 생성할 경우 Pod에 문제가 생겨 해당 Pod가 다운되거나, 종료되었을 때 쿠버네티스가 해당 Pod를 다시 생성할 수 없다.Pod에 문제가 생겨 종료되었을 때, 해당 Pod를 복구할 수 있는 쿠버네티스의 기능을 Self-Healing 이라고 한다. Self-Healing 기능을..