흔적 남기기

밑바닥부터 시작하는 웹 브라우저

궁굼하다 — Sat, 29 Nov 2025 05:32:23 +0900

챌린지를 통해 책읽기를 도전햇으나 일하면서하느라 사실 쉽지않은 여정이었다.. 그래도 이렇게 하지않으면 책 자체를 한번이라도완독을 못할수도있어 도전하게됨...

큰틀에서 전반적인 내용은 도움이되었고 내가 사용하는 웹브라우저가 참 천재들이 만드는건가 싶었는데 ㅋㅋㅋㅋㅋ

사람들은 머리가 좋다역시나..

좀 아쉽다면 다른 챌린지는 영상으로 저자가 이야기해서좋았는데 이건 좀 글로만 진행되서 아쉽....

https://www.inflearn.com/challenge/4%EC%A3%BC-%EA%B3%BC%EC%A0%95-lt%EB%B0%91%EB%B0%94%EB%8B%A5%EB%B6%80%ED%84%B0-%EC%8B%9C%EC%9E%91%ED%95%98%EB%8A%94-%EC%9B%B9/dashboard

[4주 과정] <밑바닥부터 시작하는 웹 브라우저> 완독 챌린지 챌린지 | 한빛미디어 - 인프런

그동안 ‘당연하게’ 사용만 해온 웹 브라우저, 이번엔 직접 만들면서 이해해 볼까요? 4주간의 챌린지를 통해 페이지 로딩부터 렌더링까지, 브라우저 개발자들이 직접 풀어 쓴 웹의 작동 원리를

www.inflearn.com

시스템 해킹 기초 지식

궁굼하다 — Sun, 2 Mar 2025 15:29:32 +0900

운영체제의 이해

운영체제의 개념과 기능

해킹과 보안 다루기 전에 기반이 되는 운영체제의 기본 이론 알기
시스템 이해의 필요한 요소인 운영체제 이해

운영체제의 개념

윌리엄 스탈링스 '운영체제 내부구조 및 설계 원리'에서 운영체제란 사용자가 컴퓨터 시스템을 손쉽게 사용하도록 하고, 시스템 자원을 효율적으로 관리할 수 있도록 하는 프로그램 집합으로 정의

https://velog.io/@gun_123

gun_123 (IMKUNYOUNG) - velog

[Amazon S3 Security] S3 Access Points Amazon S3는 대규모 데이터 저장 및 관리를 가능하게 하는 AWS 서비스로, 여러 사용자가 다양한 데이터에 접근할 수 있도록 설정하는 데 매우 유용합니다. 하지만 여러

velog.io

운영체제 - 응용프로그램 / 엄마 - 아이들
- 어머니는 아이들이 어떤 일을 잘 할 수 있도록 도와 준다.
- 운영체제도 프로그램이 프로세스 생성, 메모리 접근 등 서로 충돌 없이 요구를 잘 실행하도록 도와주는 역할
운영체제의 기능

https://velog.io/@0mi/

사용자 명령 인터페이스
- 사용자와 시스템의 대화 수단
- DOS나 유닉스에서는 검은색 화면에 푸른색 커서가 깜박하는 셸이 대화 수단
- 요즘은 GUI를 적용한 아이콘, 메뉴, 마우스 인터페이스를 이용
메모리 관리자
- 프로그램 코드, 데이터를 저장하는 메모리를 관리하는 프로그램
- 적합성 점검, 메모리 할당
- 할당된 메모리에 다른 프로그램이 접근하지 못하게 관리하고 보호
- 프로그램 종료 시 할당된 메모리 회수
프로세서 관리자
- 프로세서가 프로그램 코드를 구성하는 명령어(인스트럭션)을 하나씩 차례대로 수행할 때 명령어들을 체계적이고 효율적으로 실행할 수 있도록 작업 스케줄링, 사용자의 작업 요청을 수용하거나 거부 실행
장치 관리자
- 프린터, 디스크 드라이버, 모뎀, 모니터 등 시스템 안의 모든 장치를 프로그램에 할당, 회수
파일 관리자
- 시스템 안의 데이터, 응용 프로그램 등 모든 파일에 사용자별로 파일 접근 권한 부여, 저급 권한에 따라 파일을 할당 및 해제
네트워크 관리자
- 네트워크에 접근 가능한 cpu, 메모리, 프린터, 디스크 드라이버,모뎀, 모니터 같은 자원을 관리

윈도우의 이해

윈도우의 역사

1981년 10월 MS-DOS 1.0으로 시작
1983년 3월 MS-DOS 2.0, 이태부터 하드 디스크를 여러 개 장착할 수 있게 됨
1985년 11월 윈도우 1.0 발표, 다중 처리 환경, 안정성과 성능 문제로 주목은 받지 못함
1987년 윈도우 2.0 발표, DOS에서 설정한 기본 메모리인 640KB 이상의 프로그램이 생겨나기 시작
1987년 윈도우 386버전, 윈도우 3.0의 기초가 됨
윈도우 3.0은 안정성에 조금 문제가 있음에도 인기가 있었음
1992년 윈도우 3.1은 대부분의 PC에 윈도우를 설치하는 분위기 이끔
1993년 DOS에서 시작한 PC용 운영체제인 윈도우를 서버용 운영체제의 개념인 NT 버전으로 출시
1995년 8월 윈도우 95 발표, TCP/IP,전화 접속 네트워킹, 긴 파일 이름 등 새로운 기능 많아 인기
1998년 윈도우 98을 발표, OSR2 버전의 높은 안정성 선보여
1999년 윈도우 ME와 윈도우 서버 2000을 2001년 윈도우 XP, 2003년 윈도우 서버 2003 출시
이후 발전을 계속 서버 2016, 윈도우 10 등 출시 중
GUI 최초 개발 Xerox
안드로이드, IOS, 리눅스 등 OS가 점점 다양한 곳에 사용 중

윈도우의 구조

커널 : 운영체제의 중심에 위치하며, 운영체제에서 어떤 작업을 시작하더라도 커널 동작으로 제어. 커널은 인터럽트 처리, 프로세스 관리, 메모리 관리, 파일 시스템 관리, 프로그래밍 인터페이스 제공 등 운영체제 기본 기능을 제공하는 핵심

인터럽트 : 작동 중인 컴퓨터에 예기치 않은 문제가 발생한 경우 CPU가 하드웨어적으로 상태를 체크하여 변화에 대응하는 것. 인터럽트가 발생하면 운영체제의 제어 프로그램에 있는 인터럽트 처리 루틴이 작동하여 인터럽트를 해결하고, 인터럽트가 생기기 이전의 상태로 복귀

윈도우의 커널 구조
- 커널을 손상하면 안 되므로 접근 가능한 메모리에 로드하지 않는다.
- 윈도우 시스템은 보통 링 구조로 도어 있고, 맨 밑에서부터 하드웨어 - 하드웨어를 제어하는 HAL - 마이크로 커널 - 각종 관리자 - 응용프로그램 순으로 위치
- 링 구조의 계층은 각 보안 요소를 충족하고 개별적으로 운영할 때 시스템 보안 수준이 높은 상태로 유지될 것이라고 생각에서 고안
- 하드웨어 - HAL - 마이크로 커널 -각종 관리자까지를 커널 모드
- 마지막 링은 사용자 모드
- 커널 모드는 기본적으로 사용자가 접근할 수 없는 영역
- 윈도우는 사용자가 프로그램을 만들고 실행하는 모든 과정을 사용자 모드에서만 가능하도록 설계
- 하지만 완벽하게 구현은 못함 - 마이크로 커널이 HAL을 무시하고 하드웨어와 통신할 수도 있는데, 이것이 보안에서 허점을 만들어 낸다.
- 1-5 그림은 사용자 모드와 커널 모드를 좀 더 자세히 표현한 것
- 드라이버 개발자와 하드웨어 개발자는 윈도우에서 제시한 기본 표준(HAL)을 따르면 하드웨어와 개발된 소프트웨어가 원할히 통신할 수 있도록 도와주는 번역자 역할을 한다.
- HAL위에 마이크커널은 하드웨어와 통신만 제어하는 최소한의 커널을 의미하며, 프로세스 스케줄링, 메모리 관리, 데이터 입출력, 하드웨어 제어는 다른 관리자에게 분담시킴
- system32폴더의 ntoskrnl.exe파일이 그 역할을 한다.
- 위도우 관리자
  - 입출력 관리자 : 시스템의 입출력 관리, 장치 드라이버 사이에서 메시지를 전달, 응용 프로그램이 하드웨어와 곧바로 통신할 수 있는 통로 제공
  - 개체 관리자 : 윈도우는 파일, 포트 프로세스, 스레드 등 모든 것을 개체로 정의함, 이러 각 개체 정보를 제공
  - 보안 참조 관리자 : 각 데이터나 시스템 자원의 제어를 허가하거나 거부함으로써 시스템의 강제 보안 설정을 책임진다.
  - 프로세스 관리자 : 스레드 생성하고 요청에 따라 처리
  - 로컬 프로시저 호출 관리자 : 각 프로세스는 서로의 메모리 공간을 침범하지 못하기 때문에 프로세스 간 통신이 필요할 때는 이를 대신할 수 있는 장치가 필요한데, 그 장치가 로컬 프로시저 호출 관리자
  - 가상 메모리 관리자 : 응용 프로그램의 요청에 따라 RAM 메모리를 할당하고, 가상 메모리의 페이징 제어
  - 그래픽 장치 관리자 : 화면에 선이나 곡선을 그리거나 폰트 등을 관리
  - 기타 관리자 : 캐시 관리자, PNP(Plug and Play)관리자, 전원 관리자 등이 있다.
  - 윈도우는 여러 응용 프로그램을 실행할 수 있도록 몇 가지 서브시스템을 동작
    - Win32 - 32비트 응용 프로그램이 동작할 수 있게 도와줌
    - 윈도우 7이나 2008년 부터 64비트 서브시스템 제공
    - 윈도우 10부터 WSL, 리눅스 운영체제 설치하여 리눅스 프로그램도 그 안에서 실행할 수 있게 해줌
    - 서브시스템을 윈도우에서는 컨테이너라고 할 수 있음.

윈도우의 파일 시스템

FAT(File Allocation Table)은 기본적으로 2GB까지를 한 파티션으로 설정할 수 있다. FAT 테이블의 기본 크기는 16비트인데, 이는 하드 디스크에 파일을 담는 최소 단위인 클러스터가 32KB이기 때문이다.

최소 단위 클러스트 크기가 32kb 2의5승의 크기
이러한 클러스트를 저장할 수 있는 FAT 테이블의 크기는 2의16승 개수
2의16 곱하기 2의5승으니 2의 21승 즉 2GB

FAT32 클러스터를 총 32비트(2의32승)개수를 가질 수 있다. 하지만,

FAT32는 클러스터를 관리하기 위해 32비트를 사용합니다. 하지만 실제로는 28비트만 클러스터 주소에 사용되며, 나머지 4비트는 예약되어 있습니다.
따라서 FAT32는 최대 228개의 클러스터를 관리할 수 있습니다.

**섹터**는 디스크의 물리적 데이터 저장 단위이고, 클러스터는 파일 시스템이 데이터를 논리적으로 관리하기 위해 섹터를 묶은 단위입니다.
섹터 크기는 보통 고정(512바이트)되지만, 클러스터 크기는 파일 시스템에 따라 다르며 FAT32에서는 최대 32KB까지 설정할 수 있습니다.
논리적 단위

32kb 논리적 단위는 물리적 단위 1섹터 512바이트 64개필요
MBR은 디스크의 논리 섹터 수를 나타내기 위해 32비트 주소 공간을 사용합니다.
섹터 크기가 기본값인 512바이트일 때, MBR이 지원할 수 있는 최대 디스크 용량은 다음과 같습니다
따라서, MBR 기반 시스템에서는 FAT32든 다른 파일 시스템이든 간에 2TB 이상의 디스크는 주소 지정이 불가능합니다.
- MBR(Master Boot Record) 파티션 체계에서 섹터 주소를 지정할 때, 32비트 주소 공간을 사용하기 때문에 2의32승개의 주소값만 가질 수 밖에 없기때문에 2TB한계가 생김.
- MBR이 지정한 파티션 범위 내에서 FAT 테이블이 동작하므로 한계를 2TB가질 수 밖에 없지

NTFS 파일 시스템은 암호화된 폴더나 파일제공하며 복사나 이동을해도 암호화 속성을 잃지 않는다.

윈도우의 부팅 순서

운영체제의 부팅 순서는 시스템 기본을 이루는 각 요소를 보유 준다.

윈도우 xp, 윈도우 서버 2000/2003의 부팅 순서
- POST 실행 : 어떤 운영체제를 설치해도 POST 과정은 필요. 하드웨어 스스로 시스템에 문제가 없는지 기본 사항을 검사하는 과정,BIOS가 POST를 실행하고, 라우터나 스위치 등 장베에서도 처음 스위치를 켤 때 POST를 실행.
- 기본 부팅 관련 설정 사항 로드 : CMOS에서 기본 부팅 매체 등 부팅 관련 사항을 설정했던 경험이 있을 것이다. BIOS는 CMOS에 설정된 시스템 설정 사항 및 부팅과 관련된 여러 가지 정보를 읽어 시스템에 적용
- MBR 로드 : MBR은 저장 매체의 첫 번째 섹터에 위치하는 512바이트 영역으로 부팅 매체의 기본 파일 시스템 정보가 들어 있다. 파티션 테이블에서 부팅 가능한 파티션을 찾아 해당 파티션의 부트 섹터를 호출 하는 것이 주 역할.
- NTLDR 실행
- NTDETECT.com 실행 : 하드웨어를 검사

리눅스/유닉스의 이해

유닉스와 리눅스의 간단한 역사

유닉스(UNIX)

탄생 배경:
- 1969년, AT&T 벨 연구소의 **켄 톰슨(Ken Thompson)**과 **데니스 리치(Dennis Ritchie)**가 개발.
- 초기에는 어셈블리 언어로 작성되었으나, 1973년에 C 언어로 재작성되어 이식성이 크게 향상됨.
주요 특징:
- 멀티태스킹(Multi-tasking)과 다중 사용자(Multi-user) 지원.
- 계층적 파일 시스템과 높은 이식성.
- 초기 소스 코드가 대학과 연구소에 공개되어 널리 확산됨.
발전 과정:
- 유닉스는 두 가지 주요 계열로 발전:
  - System V: AT&T의 상업용 유닉스.
  - BSD(Berkeley Software Distribution): 버클리 대학에서 개발된 학문적 연구용 유닉스.
- 이후 다양한 상용 유닉스(HP-UX, AIX 등)와 오픈소스 유닉스 계열(FreeBSD 등)이 등장.

리눅스(Linux)

탄생 배경:
- 1991년, 핀란드의 대학생 **리누스 토발즈(Linus Torvalds)**가 개인 프로젝트로 개발.
- UNIX를 기반으로 하되, 상업적 제약이 없는 새로운 운영체제를 목표로 함.
- 처음에는 Minix(간단한 UNIX 계열 OS)를 대체하기 위해 시작됨.
공개와 확산:
- 1991년, 리누스가 인터넷에 리눅스 커널을 공개하며 전 세계 개발자들이 참여.
- GNU 프로젝트의 도구들과 결합하여 GNU/Linux라는 형태로 발전.
특징:
- 오픈소스 소프트웨어로 누구나 수정 및 재배포 가능(GPL 라이선스).
- 다양한 배포판(Fedora, Ubuntu, CentOS 등)으로 확산.
- 서버, 데스크톱, 임베디드 시스템 등 다양한 플랫폼에서 사용.
현재 위치:
- 리눅스는 클라우드 서버, 슈퍼컴퓨터, IoT 기기 등에서 널리 사용되며 성능과 안정성 면에서 UNIX를 능가하는 수준으로 발전.

POSIX는 Portable Operating System Interface의 약자로, 서로 다른 운영체제 간의 호환성을 유지하기 위해 정의된 표준 인터페이스입니다. 주로 유닉스(UNIX) 계열 운영체제를 기반으로 만들어졌지만, 비유닉스 계열 운영체제에서도 적용될 수 있습니다.

POSIX의 주요 목적

운영체제 간 호환성:
- POSIX는 서로 다른 운영체제에서 동일한 소스 코드가 동작하도록 하기 위해 공통 API를 정의합니다.
- 이를 통해 프로그램을 한 운영체제에서 다른 운영체제로 쉽게 이식할 수 있습니다.
표준화된 인터페이스 제공:
- 시스템 콜(C 언어 인터페이스), 파일 및 디렉토리 관리, 프로세스 환경 등 다양한 기능에 대해 표준 규격을 제공합니다.
유닉스 계열의 확장:
- POSIX는 유닉스를 기반으로 하지만, 유닉스 외의 운영체제에서도 적용 가능하도록 설계되었습니다.

POSIX의 역사

1980년대 초, 유닉스 시스템이 다양한 변종으로 발전하면서 호환성 문제가 발생했습니다.
이를 해결하기 위해 IEEE(전기전자공학자협회)가 POSIX 표준을 개발했습니다.
POSIX 표준은 1988년에 처음 발표되었으며, 이후 지속적으로 업데이트되었습니다.

POSIX의 주요 구성

POSIX는 여러 하위 표준으로 나뉘며, 대표적으로 다음과 같은 부분을 포함합니다:

POSIX.1 (C 언어 API):
- 프로세스 생성 및 종료.
- 파일 및 디렉토리 관리.
- 메모리 관리와 동기화.
POSIX.2 (쉘과 유틸리티):
- 명령어 인터프리터(쉘)와 관련 유틸리티(예: ls, cp 등).
POSIX 확장:
- 실시간 처리(POSIX.4).
- 보안 기능(POSIX.6).
- 기타 언어 지원(Ada 등).

POSIX 준수 운영체제

완전 준수:
- macOS, Solaris 등은 POSIX 인증을 받았습니다.
부분 준수:
- 대부분의 리눅스 배포판은 POSIX 표준을 따르지만, 완전 준수는 아닙니다.
비준수:
- Windows는 기본적으로 POSIX를 따르지 않지만, WSL(Windows Subsystem for Linux)과 Cygwin 등을 통해 일부 POSIX 환경을 제공합니다.

POSIX의 영향

POSIX는 현대 운영체제와 소프트웨어 개발에 큰 영향을 미쳤습니다.
이를 기반으로 유닉스 계열 운영체제와 리눅스가 발전했으며, 클라우드 서버와 같은 다양한 환경에서 널리 사용되고 있습니다.

POSIX는 운영체제 간 이식성과 호환성을 높이기 위해 IEEE가 정의한 표준 인터페이스입니다. 유닉스 계열 시스템에서 시작되었지만, 다양한 운영체제에 적용 가능하며, 소프트웨어 개발자에게 공통된 API와 규칙을 제공

POSIX는 개발자가 일관된 인터페이스(API)를 통해 소프트웨어를 작성하고 실행할 수 있도록 보장합니다.

이식성(portability):
- 이식성은 소스 코드 수준에서의 호환성을 의미합니다.
- POSIX 표준을 따르면, 한 운영체제에서 작성한 소스 코드를 다른 운영체제로 쉽게 옮길 수 있습니다.
- 예: POSIX를 준수하는 유닉스 계열 운영체제(Linux, macOS 등) 간에 동일한 소스 코드를 사용하여 프로그램을 빌드할 수 있음.
호환성(compatibility):
- 호환성은 운영체제 간에 동일한 POSIX API를 제공함으로써, 소프트웨어가 일관된 동작을 보장하도록 하는 것을 의미합니다.
- 이는 운영체제 간 상호작용을 단순화하고, 개발자가 다양한 환경에서 동일한 방식으로 작업할 수 있도록 합니다.

리눅스/유닉스의 구조

윈도우는 본래 커널이 하던 일을 여러 관리자가 분담한 반면, 유닉스 커널은 윈도우처럼 개별 관리자가 존재하지 않는다.

유닉스는 모놀리식 커널과 개별 모듈로 구성된 마이크로 커널이 있다. 유닉스의 마이크로 커널은 위도우 마이크로 커널과 달리 모듈 여러 개가 모여 커널 하나를 이루는 개념이다. 개별 모듈의 업로드와 언로드가 가능하다.

리눅스/유닉스의 부팅 순서

POST 실행
기본 부팅 관련 설정 사항 로드 from CMOS
MBR 로드
부트 로더 실행 - LILO 또는 GRUB
실행 레벨에 따른 서비스 실행
- 부트로더 스와퍼라는 pid 0번 프로세스 실행 -> 스와퍼는 pid 1번 init 프로세스 실행 -> init 프로세스 /etc/inittab 파일을 읽어 부팅할 기본 모드 선택
  - 실행 레벨
  - 0 : 시스템을 종료할 때 사용
  - 1 : 단일 사용자 모드, 관리자 권한의 셸이이지만 대부분 데몬을 실행하지 않으므로 기능은 제약되어 있음
  - 2 : NFS를 지원하지 않는 다중 사용자 모드 (네트워크 파일 시스템이 없음)
  - 3 : 일반 셸 기반의 인터페이스를 가진 다중 사용자 모드
  - 4 : 기본적으로 미사용, 사용자가 임의로 정의하여 사용 가능
  - 5 : 기본은 실행 레벨 3과 같으나, GUI 환경 지원
  - 6 : 재부팅

https://it-stargazer.com/%EC%BB%B4%ED%93%A8%ED%84%B0%EC%9D%98-%ED%95%B5%EC%8B%AC-%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C%EA%B0%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-%EC%A4%91%EC%9A%94%EC%84%B1-%EB%B0%8F-%ED%8A%B9%EC%A7%95/

컴퓨터의 핵심 운영체제가 무엇인가? 중요성 및 특징 그리고 종류와 종류별 특장점까지 IT몽상가

안녕하세요 IT몽상가 입니다. 운영체제 (Operating System, OS)는 컴퓨터 하드웨어와 사용자 간의 인터페이스 역할을 하는 소프트웨어입니다. 이는 시스템의 자원을 관리하고, 사용자의 명령을 효과적

it-stargazer.com

https://slidesplayer.org/slide/14056140/

Part01. 시스템 해킹을 위한 기초 지식 Chapter01. 운영체제에 대한 이해 - ppt download

운영체제의 개념과 기능 운영체제 개념 사용자가 컴퓨터 시스템을 손쉽게 사용하도록 하고, 시스템 자원 을 효율적으로 관리할 수 있도록 하는 프로그램 집합 운영체제란 사용자가 컴퓨터 시스

slidesplayer.org

운영체제의 개념과 기능

운영체제의 정의
컴퓨터 시스템 자원(기억장치, 프로세서, 입출력장치 등)을 효율적으로 관리하고 사용자가 시스템을 쉽게 사용할 수 있도록 돕는 프로그램 집합.
운영체제의 주요 기능
- 단일 사용자 PC: 메모리 관리자, 프로세서 관리자, 장치 관리자, 파일 관리자.
- 네트워크 지원 운영체제: 네트워크 관리자 추가.

윈도우에 대한 이해

윈도우 역사

초기 버전: MS-DOS(1981), 윈도우 1.0(1985), 윈도우 2.0(1987).
발전 과정:
- 윈도우 NT(1993): 프로세스별 고유 권한 부여.
- 윈도우 95/98: 자원 우선권 미흡.
- 이후 주요 버전: XP(2001), 서버 2003, 비스타, 윈도우 7 등.

윈도우 구조

커널(Kernel): 운영체제의 핵심으로 인터럽트 처리, 프로세스 관리, 메모리 관리 등을 수행.
링 구조: 하드웨어 → HAL → 마이크로 커널 → 관리자들 → 응용 프로그램.
- 커널 모드와 사용자 모드로 구분되며, 보안 허점이 존재.

윈도우 파일 시스템

FAT: 최대 파티션 크기 2GB, 클러스터 크기 32KB.
FAT32: 클러스터 수 증가, 타 OS와 호환성 우수.
NTFS: 파일/폴더별 권한 설정 및 암호화 지원.

윈도우 부팅 순서

POST 실행: 하드웨어 상태 점검(BIOS).
CMOS 설정 로드: 부팅 관련 정보 적용.
MBR 로드: 부팅 매체 정보 확인(512바이트 영역).
NT Loader 실행: 파일 시스템 실행 및 boot.ini 읽기.
NTDETECT.com 실행: 하드웨어 검사 및 레지스트리 생성.
ntoskrnl.exe 실행: 커널 로드 및 초기화 → 서비스 로드 → 서브 시스템 시작.

리눅스/유닉스에 대한 이해

유닉스 역사

시초: 멀틱스(Multics) 프로젝트(1963~1966).
발전 과정: 데니스 리치와 켄 톰슨이 유닉스 개발(PDP-7 기반). BSD와 System V로 분화.

리눅스 역사

GNU 프로젝트(1983)에서 시작하여 리눅스 커널(1991년) 발표. 'Copy Left' 원칙에 의해 발전.

유닉스 링 구조

구성 요소: 하드웨어 → 커널 → 셸(Shell) → 응용 프로그램.
보안 수준은 링의 개수보다 명확한 구분에 의해 결정됨.

리눅스/유닉스 커널 구조

단순한 구조로 크게 세 가지로 나뉨:
- 파일 서브 시스템(파일 저장/읽기).
- 장치 드라이버(하드웨어와 소프트웨어 연결).
- 프로세스 제어(통신, 스케줄링, 메모리 관리).

셸(Shell)

역할: 명령을 받아 커널에 전달하고 실행 결과를 반환.
주요 기능:
- 내장 명령어 제공.
- 입력/출력 방향 변경(redirection).
- 파이프라인 사용(|).
- 조건부 명령 작성 및 백그라운드 처리.

리눅스/유닉스 파일 시스템

일반 파일: 데이터/실행 파일.
디렉터리 파일: 하위 디렉터리 및 파일 정보 포함.
특수 파일: 장치 접근용(/dev 경로).
파이프 파일: 임시 파일 생성 후 명령 수행 완료 시 삭제

Networking - IP Address Management

궁굼하다 — Wed, 15 Jan 2025 01:17:49 +0900

쿠버네티스에서 **IP 주소 관리(IP Address Management, IPAM)**는 각 Pod와 가상 네트워크에 고유한 IP 주소를 할당하고 이를 관리하는 중요한 작업입니다. 이 과정은 CNI(Container Network Interface) 플러그인과 이에 속한 IPAM 플러그인을 통해 이루어집니다. 아래에서 주요 개념과 Weave CNI 플러그인을 포함한 구체적인 구현 방식을 설명합니다.

IP 주소 관리의 주요 개념

책임 주체:
- 쿠버네티스 자체는 IP 주소 할당 방법에 관여하지 않습니다. 대신, 네트워크 솔루션 제공자인 CNI 플러그인이 이 작업을 담당합니다
- CNI 플러그인은 Pod에 네트워크 인터페이스를 설정하고, IPAM 플러그인을 호출하여 IP 주소를 할당합니다
IP 주소 할당 방식:
- 각 노드에는 **Pod CIDR(Cluster-wide Subnet)**가 할당되며, 해당 노드의 Pod들은 이 범위 내에서 IP를 받습니다
- CNI 구성 파일의 ipam 섹션에서 사용할 IPAM 플러그인 유형과 서브넷 등을 정의할 수 있습니다
중복 방지:
- IPAM 플러그인은 클러스터 내에서 중복되지 않는 고유한 IP를 보장합니다. 이를 위해 로컬 데이터베이스 파일이나 중앙 저장소에 할당 정보를 기록합니다

CNI와 기본 IPAM 플러그인

Host-Local 플러그인:
- 각 노드별로 로컬 데이터베이스를 사용해 IP를 관리합니다.
- 설정 예시:

{
  "type": "host-local",
  "subnet": "10.22.0.0/16",
  "routes": [{ "dst": "0.0.0.0/0" }]
}

구성 요소 설명

"type": 사용할 CNI 플러그인(예: bridge, host-local).
"subnet": 사용할 IP 주소 대역(예: 10.22.0.0/16).
"routes": 트래픽 라우팅 경로(예: 모든 트래픽(0.0.0.0/0) 허용).

host-local: 각 호스트별로 IP 주소를 관리하는 로컬 IPAM 솔루션입니다. 이 플러그인은 지정된 서브넷에서 IP 주소를 할당하며, 각 노드는 독립적으로 IP 주소 범위를 관리합니다.

DHCP 플러그인:

DHCP 서버를 사용하여 동적으로 IP를 할당합니다.
네트워크 외부와의 통합이 필요한 경우 유용합니다

Whereabouts:

클러스터 전체에서 중앙 집중식으로 IP 범위를 관리하며, 데이터 저장소를 사용하여 상태를 추적합니다.
설정 예시:

{
  "type": "whereabouts",
  "range": "192.168.2.0/24"
}

https://www.cni.dev/plugins/current/ipam/

CNI

www.cni.dev

https://dougbtv.com/nfvpe/2019/11/27/whereabouts-a-cluster-wide-cni-ipam-plugin/

Whereabouts -- A cluster-wide CNI IP Address Management (IPAM) plugin · dougbtv

Whereabouts -- A cluster-wide CNI IP Address Management (IPAM) plugin 27 Nov 2019 Something that’s a real challenge when you’re trying to attach multiple networks to pods in Kubernetes is trying to get the right IP addresses assigned to those interface

dougbtv.com

https://gornoba.github.io/devops/kubernetes/networking/ip-address-management

쿠버네티스에서의 IP 주소 관리 (IPAM) | Hyunhoo's blog

gornoba.github.io

https://docs.tigera.io/calico/latest/networking/ipam/get-started-ip-addresses

Get started with IP address management | Calico Documentation

Configure Calico to use Calico IPAM or host-local IPAM, and when to use one or the other.

docs.tigera.io

Weave CNI 플러그인의 IPAM 구현

기본 동작:
- Weave는 기본적으로 10.32.0.0/12 범위를 사용하여 약 100만 개의 IP를 제공합니다
- 이 범위는 클러스터의 모든 노드 간에 균등하게 분할되며, 각 노드는 자신에게 할당된 서브넷 내에서 Pod에 IP를 할당합니다.
구성 가능 옵션:
- 사용자 정의 범위를 설정하려면 Weave 배포 시 --ipalloc-range 옵션을 사용합니다.

weave launch --ipalloc-range 10.200.0.0/16

CNI 플러그인 설정 확인: /etc/cni/net.d/ 디렉토리에서 확인 가능.
Weave의 네트워크 범위 확인: ip addr show weave 명령어 사용.
포드의 라우팅 정보 확인: kubectl exec <pod-name> -- ip route

Networking - weave cni

궁굼하다 — Wed, 15 Jan 2025 01:03:15 +0900

Weave CNI 플러그인의 작동 방식

Weave CNI는 Kubernetes 클러스터 내에서 메시 오버레이 네트워크를 생성하여 모든 노드와 파드를 연결합니다. 각 노드에는 Weave 에이전트가 배포되며, 이 에이전트들은 서로 통신하여 클러스터의 네트워크 토폴로지를 유지하고 업데이트합니다. 이를 통해 다음과 같은 과정을 수행합니다:

패킷 캡슐화 및 전송:
- 한 파드에서 다른 노드의 파드로 패킷이 전송될 때, Weave 에이전트는 해당 패킷을 가로채고 캡슐화(encapsulation)합니다.
- 캡슐화된 패킷은 네트워크를 통해 대상 노드로 전송됩니다.
- 대상 노드의 Weave 에이전트는 패킷을 디캡슐화(decapsulation)하여 올바른 파드로 전달합니다
IP 주소 관리:
- Weave는 10.32.0.0/12 범위의 IP 주소를 사용하여 각 노드와 파드에 고유한 IP를 할당합니다.
- 중복 IP 할당을 방지하기 위해 각 노드가 IP 범위를 동적으로 나누어 관리합니다
라우팅 최적화:
- Weave는 자동으로 네트워크 경로를 설정하여 효율적인 데이터 전송을 보장하며, 패킷 손실을 최소화합니다.
- VXLAN 프로토콜을 사용하여 네트워크 트래픽을 캡슐화하고 라우팅합니다

Weave CNI의 주요 특징

확장성 및 안정성:
- 대규모 클러스터에서도 안정적으로 작동하며, 자동 복구(self-healing) 기능을 제공합니다
네트워크 정책 지원:
- Weave는 Kubernetes의 네트워크 정책(NetworkPolicy)을 지원하며, 이를 통해 특정 파드 간 통신을 허용하거나 차단할 수 있습니다
암호화 지원:
- 네트워크 트래픽 암호화를 제공하여 보안을 강화할 수 있습니다(옵션 설정 필요)
다중 브리지 연결:
- 하나의 파드는 Weave 브리지와 Docker 브리지 등 여러 네트워크에 동시에 연결될 수 있습니다

Weave CNI 설치 방법

Weave CNI 플러그인을 설치하려면 Kubernetes 클러스터가 사전에 준비되어 있어야 합니다. 설치 과정은 다음과 같습니다:

# 설치 명령 실행
kubectl apply -f https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s.yaml

# 설치 확인
kubectl get pods -n kube-system -l name=weave-net -o wide

# 네트워크 상태 점검
kubectl exec -n kube-system weave-net-<pod-name> -- /home/weave/weave status

Weave CNI는 Kubernetes 클러스터에서 안정적이고 확장 가능한 네트워킹 솔루션을 제공하며, 특히 대규모 환경에서 효과적으로 작동합니다. 이를 통해 복잡한 라우팅 테이블 설정 없이도 효율적인 컨테이너 간 통신을 구현할 수 있습니다.

장점	한계
간단한 설치 및 구성	높은 메모리 사용량 가능성
자동 IP 할당 및 경로 최적화	암호화 활성화 시 성능 저하
대규모 클러스터에서 확장성 우수	일부 고급 기능 설정 필요

https://haejun-kim.tistory.com/27

[CKA] Network

Linux Network Basics 쿠버네티스의 Network를 살펴보기 전에 이해하는데 도움이 되는 전제 조건들을 미리 학습한 후, 쿠버네티스의 network를 살펴보도록 한다. 구체적으로는 Switching and Routing, DNS, Netwrok N

haejun-kim.tistory.com

https://muni-dev.tistory.com/entry/Udemy-CKA-%EA%B0%95%EC%9D%98-%EC%A0%95%EB%A6%AC-211-CNI-weave

Udemy CKA 강의 정리 211: CNI weave

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다. ⚠️ 영어 독

muni-dev.tistory.com

https://seungjuitmemo.tistory.com/232#google_vignette

https://cwal.tistory.com/9

https://kubernetes.io/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/

https://overcast.blog/choosing-the-right-container-network-interface-plugin-in-kubernetes-45391c7d4cc8

https://ranchermanager.docs.rancher.com/faq/container-network-interface-providers

https://www.kloia.com/blog/why-do-we-use-cni-plugins-on-kubernetes

https://blog.pscr.me/102?category=1169431

Inspect the kubelet service and identify the container runtime endpoint value is set for Kubernetes.

ps -aux | grep -i kubelet | grep container-runtime
root        4191  0.0  0.1 2931492 88284 ?       Ssl  15:40   0:05 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock --pod-infra-container-image=registry.k8s.io/pause:3.10

What is the path configured with all binaries of CNI supported plugins?

/opt/cni/bin

What is the CNI plugin configured to be used on this kubernetes cluster?

ls /etc/cni/net.d/
- 10-flannel.conflist

What binary executable file will be run by kubelet after a container and its associated namespace are created?

cat 10-flannel.conflist

controlplane ~ ➜  cat /etc/cni/net.d/10-flannel.conflist 
{
  "name": "cbr0",
  "cniVersion": "0.3.1",
  "plugins": [
    {
      "type": "flannel",
      "delegate": {
        "hairpinMode": true,
        "isDefaultGateway": true
      }
    },
    {
      "type": "portmap",
      "capabilities": {
        "portMappings": true
      }
    }
  ]
}

Deploy weave-net networking solution to the cluster.
NOTE: - We already have provided a weave manifest file under the /root/weave directory.

configmap의 kube-proxy에서 cidr확인

k describe cm kube-proxy -n kube-system
Name:         kube-proxy
Namespace:    kube-system
Labels:       app=kube-proxy
Annotations:  kubeadm.kubernetes.io/component-config.hash: sha256:906b8697200819e8263843f43965bb3614545800b82206dcee8ef93a08bc4f4b

Data
====
config.conf:
----
apiVersion: kubeproxy.config.k8s.io/v1alpha1
bindAddress: 0.0.0.0
bindAddressHardFail: false
clientConnection:
  acceptContentTypes: ""
  burst: 0
  contentType: ""
  kubeconfig: /var/lib/kube-proxy/kubeconfig.conf
  qps: 0
clusterCIDR: 10.244.0.0/16
configSyncPeriod: 0s
conntrack:
  maxPerCore: null

containers.env에서 name, value값 설정

Networking - Pod Networking

궁굼하다 — Wed, 15 Jan 2025 00:28:29 +0900

Kubernetes에서 Pod 네트워킹

1. Kubernetes 네트워크 설정 개요

Kubernetes 클러스터를 구성할 때, 노드 간 통신을 위한 네트워크는 이미 설정되어 있습니다. 그러나 Pod 레벨의 네트워킹은 별도로 구현해야 합니다. Kubernetes는 기본적으로 Pod 네트워크에 대한 솔루션을 제공하지 않으며, 사용자가 이를 직접 설정해야 합니다.Pod 네트워킹의 주요 요구사항은 다음과 같습니다:

각 Pod는 고유한 IP 주소를 가져야 합니다.
동일한 노드 내의 모든 Pod는 서로 통신할 수 있어야 합니다.
다른 노드에 있는 Pod와도 동일한 IP 주소를 사용하여 통신할 수 있어야 합니다.
NAT(Network Address Translation) 규칙 없이 통신이 가능해야 합니다.

2. Pod 네트워크 구현 계획

Pod 네트워크를 구현하기 위해 다음과 같은 단계를 수행합니다:

노드 네트워크

노드는 외부 네트워크(예: 192.168.1.x 대역)에 연결되어 있으며, 각 노드는 고유한 IP 주소를 가집니다(예: 192.168.1.11, 192.168.1.12, 192.168.1.13).

Bridge 네트워크 생성

각 노드에서 Bridge 네트워크를 생성합니다.
Bridge 네트워크는 각 노드 내 컨테이너 네임스페이스를 연결하는 역할을 합니다.
예시로, 각 Bridge 네트워크에 다음과 같은 서브넷을 할당합니다:
- Node 1: 10.240.1.0/24
- Node 2: 10.240.2.0/24
- Node 3: 10.240.3.0/24

컨테이너 연결

컨테이너를 Bridge 네트워크에 연결하기 위해 다음 작업을 수행합니다:

가상 네트워크 인터페이스 생성: ip link add 명령어로 컨테이너와 Bridge를 연결하는 가상 케이블 생성.
IP 주소 할당: ip addr 명령어로 컨테이너에 IP 주소 할당(예: 10.244.x.x).
라우팅 설정: ip route 명령어로 기본 게이트웨이 경로 추가.
인터페이스 활성화: ip link set 명령어로 인터페이스 활성화.

노드 간 라우팅

서로 다른 노드의 Pod 간 통신을 위해 라우팅 테이블을 설정합니다.
예를 들어, Node 1의 Pod(10.244.1.x)가 Node 2의 Pod(10.244.2.x)와 통신하려면, Node 1의 라우팅 테이블에 Node 2 서브넷(10.244.2.x)을 가리키는 경로를 추가해야 합니다.

3. 확장 가능한 솔루션

위의 방식은 소규모 클러스터에서는 작동하지만, 대규모 환경에서는 비효율적입니다:

모든 노드에 수동으로 라우팅 테이블을 추가하는 것은 비현실적입니다.
대신, 라우터를 사용하여 중앙 집중식으로 라우팅 테이블을 관리하거나 Kubernetes의 CNI(Container Network Interface)를 활용합니다.

4. CNI(Container Network Interface)

CNI는 Kubernetes와 사용자 정의 스크립트를 연결하는 표준 인터페이스입니다:

CNI는 Pod 생성 시 스크립트를 자동으로 실행하여 네트워크 설정을 처리합니다.
스크립트는 다음과 같은 두 가지 섹션으로 구성됩니다:
- Add 섹션: 컨테이너를 네트워크에 추가.
- Delete 섹션: 컨테이너 삭제 시 인터페이스 제거 및 IP 주소 반환.

Kubernetes는 CNI 플러그인을 통해 Pod가 생성될 때 해당 스크립트를 실행하며, 이를 통해 자동화된 네트워킹 환경을 제공합니다.

https://doitnow-man.tistory.com/entry/CKA-28-Pod%EC%9D%98-Networking

Note CNI Weave

Important Update: -

Before going to the CNI weave lecture, we have an update for the Weave Net installation link. They have announced the end of service for Weave Cloud.

To know more about this, read the blog from the link below: -

https://www.weave.works/blog/weave-cloud-end-of-service

As an impact, the old weave net installation link won’t work anymore: -

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

Instead of that, use the below latest link to install the weave net: -

kubectl apply -f https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s.yaml

Reference links: -

Networking - Docker Networking - CNI - CLuster Networking

궁굼하다 — Wed, 15 Jan 2025 00:08:39 +0900

1. None 네트워크

특징: 컨테이너가 네트워크에 연결되지 않으며, 외부 세계와 완전히 격리됩니다.
동작: 컨테이너 내부에는 루프백 인터페이스(lo)만 생성되며, IP 주소가 할당되지 않습니다. 따라서 외부 네트워크로의 접속이나 다른 컨테이너와의 통신이 불가능합니다.
사용 사례: 네트워크 연결이 필요 없는 배치 작업(batch job)이나 보안이 중요한 환경에서 사용됩니다.
예시 명령어:

docker run --network none ubuntu

https://learning-ocean.com/tutorials/docker/docker-docker-none-network/

Docker - Docker None Network - Learning-Ocean

Docker Networking (Null Network, None Network) none network in docker means when you don\'t want any network interface for

learning-ocean.com

https://docs.docker.com/engine/network/drivers/none/

None network driver

How to isolate the networking stack of a container using the none driver

docs.docker.com

2. Host 네트워크

특징: 컨테이너가 호스트의 네트워크 스택을 공유하며, 별도의 네트워크 격리가 없습니다.
동작:
- 컨테이너는 호스트와 동일한 IP 주소를 사용하며, 포트 매핑(port mapping)이 필요하지 않습니다.
- 동일한 포트를 사용하는 여러 컨테이너를 실행할 수 없으므로 포트 충돌 문제가 발생할 수 있습니다.
사용 사례: 높은 성능이 요구되거나, 호스트 네트워크에 직접 접근해야 하는 애플리케이션(예: 모니터링 도구)에서 사용됩니다.
예시 명령어:

docker run --network host nginx

https://www.geeksforgeeks.org/what-is-docker-network-host/

What Is Docker Network Host ? - GeeksforGeeks

A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.

www.geeksforgeeks.org

https://docs.docker.com/engine/network/drivers/host/

Host network driver

All about exposing containers on the Docker host's network

docs.docker.com

3. Bridge 네트워크

특징: 도커가 기본적으로 제공하는 네트워크 모드로, 소프트웨어 브리지를 통해 컨테이너 간 통신을 지원합니다.
동작:
- 각 컨테이너는 독립적인 IP 주소를 할당받으며, 기본적으로 172.17.0.0/16 서브넷을 사용합니다.
- NAT(Network Address Translation)를 통해 외부 인터넷과 통신할 수 있습니다.
- 다른 브리지 네트워크에 연결된 컨테이너와는 격리됩니다.
사용 사례: 개발 및 테스트 환경에서 로컬 컨테이너 간 통신을 설정할 때 유용합니다.
예시 명령어:

docker run --network bridge nginx

https://docs.docker.com/engine/network/drivers/bridge/

Bridge network driver

All about using user-defined bridge networks and the default bridge

docs.docker.com

https://www.geeksforgeeks.org/what-is-docker-network-bridge/

What is Docker Network Bridge? - GeeksforGeeks

www.geeksforgeeks.org

포트 매핑 (Port Mapping)

컨테이너 내부 애플리케이션에 외부에서 접근하려면 포트를 매핑해야 합니다.

동작 방식

도커는 iptables를 사용하여 NAT 규칙을 생성합니다.
호스트의 특정 포트를 컨테이너 내부 포트로 전달합니다.

예시

docker run -p 8080:80 nginx

https://iximiuz.com/en/posts/docker-publish-container-ports/

What Actually Happens When You Publish a Container Port

Have you ever wondered what actually happens when you ask Docker to publish a port? How port publishing implementation differs between Docker Engine and Docker Desktop? How to publish a port with containerd? How nerdctl and Lima implement port forwarding?

iximiuz.com

도커(Docker)는 리눅스의 iptables를 활용하여 네트워크 격리, 포트 매핑(port mapping), 그리고 NAT(Network Address Translation)와 같은 네트워킹 기능을 제공합니다. 아래는 도커와 관련된 iptables 설정 및 명령어에 대한 설명입니다.

1. iptables와 도커의 관계

도커는 컨테이너 네트워킹을 위해 자동으로 iptables 규칙을 생성합니다.
주요 체인:
- DOCKER: 도커가 생성한 기본 체인으로, 포트 매핑 및 NAT 규칙이 포함됩니다.
- DOCKER-USER: 사용자가 커스텀 규칙을 추가할 수 있는 체인입니다. 이 체인은 DOCKER 체인보다 먼저 실행됩니다

2. 기본 iptables 체인과 규칙

도커가 생성하는 주요 iptables 규칙은 다음과 같습니다:

(1) NAT 테이블

- NAT 테이블은 네트워크 주소 변환(Network Address Translation)을 처리합니다.
- 주요 규칙:

# PREROUTING 체인: 외부에서 들어오는 패킷을 컨테이너로 전달
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER

# POSTROUTING 체인: 컨테이너에서 나가는 패킷의 출발지 주소를 호스트 주소로 변환
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE

(2) FORWARD 체인

컨테이너 간 통신 또는 외부 네트워크와의 통신을 허용합니다.
주요 규칙

# 컨테이너 간 트래픽 허용
-A FORWARD -i docker0 -o docker0 -j ACCEPT

# 외부에서 컨테이너로 들어오는 트래픽 허용
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# 컨테이너에서 외부로 나가는 트래픽 허용
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT

3. 포트 매핑과 iptables

도커는 -p 플래그를 사용하여 호스트와 컨테이너 간 포트를 매핑합니다. 예를 들어, docker run -p 8080:80 명령어는 호스트의 포트 8080을 컨테이너의 포트 80에 연결합니다.

iptables에서의 동작

포트 매핑은 NAT 테이블의 PREROUTING 및 DOCKER 체인을 통해 구현됩니다:

# PREROUTING: 외부에서 들어오는 트래픽을 컨테이너로 전달
-A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 172.17.0.2:80

# POSTROUTING: 컨테이너에서 나가는 트래픽의 출발지 주소를 호스트 주소로 변환
-A POSTROUTING -s 172.17.0.2/32 ! -o docker0 -j MASQUERADE

위 규칙은 다음과 같은 동작을 수행합니다:

외부에서 호스트의 8080 포트로 들어온 요청은 컨테이너의 내부 IP(172.17.0.2)와 포트(80)로 전달됩니다.
컨테이너에서 나가는 트래픽은 호스트 IP를 사용하여 외부 네트워크와 통신합니다

4. 사용자 정의 iptables 규칙 추가

사용자는 DOCKER-USER 체인을 활용하여 커스텀 방화벽 규칙을 추가할 수 있습니다.

예제: 특정 IP만 허용

다음 명령어는 특정 IP(192.168.1.1)만 도커 컨테이너에 접근할 수 있도록 설정합니다:

# 특정 IP만 허용하고 나머지는 차단
iptables -I DOCKER-USER -i eth0 ! -s 192.168.1.1 -j DROP

예제: 특정 포트 차단

호스트의 특정 포트를 차단하려면 다음과 같이 설정합니다:

# TCP 포트 8080 차단
iptables -I DOCKER-USER -p tcp --dport 8080 -j DROP

5. iptables 규칙 확인 및 관리

규칙 확인

현재 설정된 iptables 규칙을 확인하려면 다음 명령어를 사용합니다:

sudo iptables -t nat -L    # NAT 테이블 확인
sudo iptables -L           # 필터 테이블 확인

https://docker-docs.uclv.cu/network/iptables/

Packet filtering and firewalls

How Docker works with packet filtering, iptables, and firewalls

docs.docker.com

https://dustinspecker.com/posts/iptables-how-docker-publishes-ports/

iptables: How Docker Publishes Ports

The next question to answer after writing How do Kubernetes and Docker create IP Addresses?! is “How does Docker handle publishing ports?” In the previous post, we created our own network namespaces, virtual interfaces, and assigned IP addresses to the

dustinspecker.com

https://blog.ipspace.net/kb/DockerSvc/30-nat-iptables/

Docker Implementation of Published Ports « ipSpace.net blog

The default single-host Docker networking implementation uses iptables NAT table to implement published ports (Docker Swarm uses a load balancer on every swarm member), and in this part of the article we’ll decode the intricate setup it has to use to get

blog.ipspace.net

https://www.endpointdev.com/blog/2024/06/docker-and-iptables/

Docker and iptables | End Point Dev

Introduction on how to use iptables to block access to Docker containers.

www.endpointdev.com

https://docker-docs.uclv.cu/network/iptables/

Packet filtering and firewalls

How Docker works with packet filtering, iptables, and firewalls

docs.docker.com

https://forums.docker.com/t/how-to-configure-docker-networking-with-docker-compose-to-enable-remote-access-to-docker-container-via-ip/96990

How to configure docker networking with docker-compose to enable remote access to docker container via IP?

This question seems to be quite common but I’ve never found a satisfactory answer to it. In addition w.r.t. setting up the network with docker-compose instead of plain docker there is additional confusion e.g. cause of Support IPAM gateway in version 3.x

forums.docker.com

https://inspirit941.tistory.com/415

CKA 대비 kubernetes 스터디 - 8. Networking (1)

알아둬야 할 Linux Networking Prerequisite 내용. Basics : Linux Networking A가 B에게 통신하려면? Switch에 연결한다. -> switch는 두 개의 시스템을 연결하는 네트워크를 생성한다. switch에 연결하기 위해서는, 각

inspirit941.tistory.com

https://velog.io/@h13m0n/8

https://dev-chicken.tistory.com/66#google_vignette

https://ikcoo.tistory.com/417

https://www.cncf.co.kr/community/container-network-interface/

**CNI(Container Network Interface)**는 컨테이너 환경에서 네트워크를 구성하고 관리하기 위한 표준 인터페이스입니다. 이는 다양한 컨테이너 런타임(예: Kubernetes, Mesos 등)과 네트워크 플러그인 간의 상호작용을 표준화하여 컨테이너 네트워킹의 복잡성을 줄이고 유연성을 제공합니다.

CNI의 주요 개념

1. 표준화된 인터페이스

CNI는 컨테이너 런타임과 네트워크 플러그인이 통합될 수 있도록 명확한 사양을 정의합니다.
이를 통해 컨테이너 생성 시 네트워크 연결, 삭제 시 네트워크 리소스 해제 등의 작업을 자동화합니다

2. 유연성과 확장성

CNI는 플러그인 기반 아키텍처를 채택하여 다양한 네트워크 요구사항에 맞게 확장 가능합니다.
JSON 형식의 설정 파일을 사용해 네트워크 구성을 정의하고 관리합니다

3. 경량 아키텍처

CNI는 간단하고 효율적인 설계를 통해 빠르고 유연한 네트워크 구성을 지원하며, 불필요한 복잡성을 줄입니다

CNI의 동작 방식

컨테이너 런타임의 역할

각 컨테이너에 대해 네트워크 네임스페이스(Network Namespace)를 생성합니다.
컨테이너가 연결해야 할 네트워크를 식별합니다.
CNI 플러그인을 호출해 ADD 명령으로 네트워크를 설정하고, 컨테이너 삭제 시 DEL 명령으로 정리합니다.

플러그인의 역할

ADD, DEL, CHECK 명령을 지원하며, 각 명령은 컨테이너 ID와 네트워크 네임스페이스 등의 매개변수를 받습니다.
IP 주소를 할당하고, 필요한 라우팅 정보를 설정합니다.
작업 결과를 표준 형식으로 반환하여 런타임과의 일관성을 유지합니다

CNI 플러그인

CNI는 기본적으로 여러 플러그인을 지원하며, 각 플러그인은 특정 네트워크 요구사항에 맞게 설계되었습니다.

기본 제공 플러그인

Bridge: Linux 브릿지를 생성해 컨테이너를 연결.
MACVLAN/IPVLAN: 물리적 인터페이스와 직접 연결.
Host-local: 로컬 IP 주소 할당.
Portmap: 포트 매핑을 관리

서드파티 플러그인

Calico: 대규모 클러스터에서 강력한 보안 및 정책 관리 제공.
Flannel: 간단한 오버레이 네트워크 구현.
Cilium: eBPF 기반 고성능 패킷 필터링 및 L7 정책 지원

CNI와 Docker의 차이점

Docker는 자체적인 네트워킹 표준인 CNM(Container Network Model)을 사용하며, CNI와는 다른 방식으로 작동합니다:

CNM은 Docker에 특화된 설계로, CNI와 호환되지 않습니다.
Kubernetes는 Docker 컨테이너를 생성할 때 기본적으로 CNI 플러그인을 호출하여 추가적인 네트워크 구성을 수행합니다

Kubernetes와 CNI

Kubernetes는 CNI를 사용해 Pod 간 통신 및 외부 네트워크 연결을 관리합니다:

kubelet(컨테이너 런타임 관리자)이 각 노드에서 CNI 플러그인을 호출하여 Pod의 네트워크를 설정합니다.
IPAM(IP Address Management)을 통해 Pod에 고유 IP 주소를 할당하고 라우팅 테이블을 구성합니다

CNI의 장점

표준화: 다양한 런타임과 플러그인이 호환 가능.
유연성: 사용자 환경에 맞게 플러그인 선택 가능.
확장성: 멀티 노드 및 대규모 클러스터에서도 안정적으로 작동

결론적으로, CNI는 현대적인 컨테이너 환경에서 필수적인 기술로 자리 잡았으며, Kubernetes와 같은 플랫폼에서 특히 중요한 역할을 담당합니다.

Kubernetes 클러스터의 네트워킹 요구사항

Kubernetes 클러스터는 마스터 노드와 워커 노드로 구성됩니다. 각 노드는 최소 하나 이상의 네트워크 인터페이스를 가져야 하며, 해당 인터페이스는 IP 주소가 설정되어 있어야 합니다. 또한, 모든 호스트는 고유한 호스트 이름과 MAC 주소를 가져야 합니다. 이는 특히 기존 가상 머신(VM)을 복제하여 생성한 경우 주의해야 할 사항입니다.

필수적으로 열어야 할 포트

Kubernetes 클러스터에서 다양한 구성 요소가 통신하기 위해 특정 포트를 열어야 합니다. 주요 포트는 다음과 같습니다:

API 서버 (마스터 노드)
- 포트 6443: Kubernetes API 서버가 외부 요청(kubectl, 워커 노드, 외부 사용자 등)을 수신하는 데 사용됩니다.
Kubelet (마스터 및 워커 노드)
- 포트 10250: 마스터와 워커 노드 모두에서 Kubelet이 사용하는 포트입니다.
스케줄러 (마스터 노드)
- 포트 10259: kube-scheduler가 사용하는 포트입니다.
컨트롤러 매니저 (마스터 노드)
- 포트 10257: kube-controller-manager가 사용하는 포트입니다.
ETCD 데이터베이스
- 포트 2379: ETCD 서버가 클라이언트 요청을 수신하는 데 사용됩니다.
- 포트 2380: 여러 마스터 노드 간 ETCD 통신에 사용됩니다.
NodePort 서비스 (워커 노드)
- 포트 범위 30000~32767: 외부 트래픽을 처리하기 위해 워커 노드에서 서비스가 사용하는 포트 범위입니다.

네트워크 보안 구성

방화벽, IP 테이블 규칙 또는 클라우드 환경(GCP, Azure, AWS)의 네트워크 보안 그룹에서 위의 포트를 열어야 합니다.
TLS 암호화를 통해 데이터 통신의 무결성과 기밀성을 보장해야 합니다

멀티 마스터 환경

멀티 마스터 환경에서는 위에서 언급한 모든 포트를 각 마스터 노드에서 열어야 하며, 추가적으로 ETCD 간 통신을 위한 포트(2380)를 열어야 합니다

네트워크 디버깅 및 관리

kubectl get nodes 명령으로 클러스터의 각 노드 정보를 확인할 수 있습니다.
kubectl get pods -o wide 명령을 사용하여 Pod의 IP 주소와 위치를 확인할 수 있습니다.
네트워크 연결 문제를 조사할 때 kubectl exec 명령으로 Pod 내부에 접속하여 ping, nslookup 같은 네트워크 진단 도구를 사용할 수 있습니다

추가 고려사항

Kubernetes는 Pod 간 통신을 위해 컨테이너 네트워크 인터페이스(CNI) 플러그인을 사용합니다. Calico, Flannel과 같은 CNI 플러그인을 설치하여 네트워크 정책을 설정하거나 성능을 최적화할 수 있습니다
Pod 네트워크 CIDR 범위는 호스트 네트워크와 겹치지 않도록 설정해야 합니다

이러한 설정은 Kubernetes 클러스터의 안정성과 보안을 유지하는 데 필수적이며, 클러스터 배포 전 반드시 확인해야 합니다.

https://www.getambassador.io/blog/kubernetes-networking-guide-top-engineers

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/

https://abhirajdevops.hashnode.dev/a-cheat-sheet-of-essential-commands-for-managing-and-debugging-your-kubernetes-clusters-networking

Networkgin - Prerequisite - Switching Routing-DNS-CoreDNS-Network Namespaces

궁굼하다 — Tue, 14 Jan 2025 17:56:31 +0900

1. 네트워크의 기본 개념

네트워크란?
- 두 컴퓨터(예: A와 B)가 서로 통신하려면 네트워크가 필요합니다.
- 네트워크를 구성하려면 스위치(Switch)를 사용하며, 각 컴퓨터는 네트워크 인터페이스(물리적 또는 가상)를 통해 스위치와 연결됩니다.
스위칭(Switching)
- 스위치는 동일한 네트워크 내에서 데이터를 전달합니다.
- 예: A와 B가 같은 네트워크(192.168.1.0)에 있을 때, 스위치를 통해 서로 통신 가능.
라우팅(Routing)
- 라우터는 서로 다른 네트워크를 연결합니다.
- 예: 네트워크 192.168.1.0과 192.168.2.0 사이에서 데이터를 전달하려면 라우터가 필요합니다.
- 라우터는 두 네트워크에 각각 IP 주소를 할당받아야 합니다.
게이트웨이(Gateway)
- 게이트웨이는 한 네트워크에서 다른 네트워크로 나가는 "문" 역할을 합니다.
- 각 시스템은 게이트웨이를 통해 다른 네트워크와 통신할 수 있습니다.

2. Linux에서의 기본 명령어

IP 링크 확인: ip link
- 호스트의 네트워크 인터페이스를 확인합니다.
IP 주소 확인 및 설정:
- 확인: ip addr
- 설정: ip addr add [IP주소] dev [인터페이스 이름]
라우팅 테이블 확인 및 추가:
- 확인: route 또는 ip route
- 추가: ip route add [목적지 네트워크] via [게이트웨이 IP]

3. 라우터 설정 및 패킷 전달

라우터 역할을 하는 호스트 구성:
- 두 개의 네트워크에 연결된 호스트(B)를 라우터로 설정하여 A와 C 간 통신 가능하게 만듭니다.
패킷 전달 활성화:
- 기본적으로 Linux에서는 보안상의 이유로 패킷 전달이 비활성화되어 있습니다.
- 활성화 방법:

echo 1 > /proc/sys/net/ipv4/ip_forward

(영구 적용하려면 /etc/sysctl.conf 파일 수정 필요)

4. DNS 및 인터넷 연결

DNS란?
- 도메인 이름(예: www.google.com)을 IP 주소로 변환하는 시스템입니다.
기본 게이트웨이 설정:
- 인터넷에 연결하려면 라우터를 인터넷에 연결하고, 기본 게이트웨이를 설정해야 합니다.
- 예: 모든 외부 네트워크 트래픽을 특정 라우터로 보내도록 설정.

쉽게 이해하기 위한 비유

스위치: 한 방 안에서 사람들끼리 대화할 수 있도록 돕는 중재자
라우터: 서로 다른 방(네트워크)을 연결해주는 문지기
게이트웨이: 집 밖으로 나가는 대문
DNS: 사람 이름을 전화번호로 바꿔주는 전화번호부

DNS(Domain Name System) 이해

DNS란?

DNS는 사람이 이해하기 쉬운 도메인 이름(예: www.google.com)을 컴퓨터가 이해할 수 있는 IP 주소(예: 172.217.194.0)로 변환하는 시스템입니다.
작은 네트워크에서는 /etc/hosts 파일에 이름과 IP 주소를 직접 매핑하여 사용할 수 있습니다.

/etc/hosts 파일 사용

/etc/hosts 파일에 다음 형식으로 이름과 IP를 추가:

192.168.1.11 db

이렇게 하면 db라는 이름으로 해당 IP를 참조할 수 있습니다.

DNS 서버 사용

큰 네트워크에서는 중앙에서 관리되는 DNS 서버가 필요합니다.
DNS 서버 설정:
- /etc/resolv.conf 파일에 다음과 같이 DNS 서버 IP 추가:

nameserver 192.168.1.100

DNS 작동 방식

이름 해석(Name Resolution)

호스트가 이름을 IP로 변환하는 과정입니다.
순서:
1. 먼저 /etc/hosts 파일을 확인
2. 없으면 DNS 서버로 요청

도메인 이름 구조

도메인 이름은 계층 구조로 구성됩니다:
- 예: www.google.com
  - www: 서브도메인
  - google: 도메인 이름
  - .com: 최상위 도메인(TLD)

DNS 레코드 유형

A 레코드: IPv4 주소와 이름 매핑
AAAA 레코드: IPv6 주소와 이름 매핑
CNAME 레코드: 별칭(다른 이름) 매핑

실습 예제

작은 네트워크에서의 설정

두 컴퓨터 A(192.168.1.10)와 B(192.168.1.11)가 같은 네트워크에 연결되어 있다고 가정.
B의 이름을 db로 설정하려면 A의 /etc/hosts 파일에 다음 추가:

192.168.1.11 db

A에서 ping db 명령어 실행 시 B로 연결 가능.

DNS 서버 설정

내부 DNS 서버를 사용하려면 모든 호스트의 /etc/resolv.conf 파일에 다음 추가:

nameserver 192.168.1.100

외부 인터넷 사이트(예: www.facebook.com)를 접근하려면 공용 DNS 서버(예: Google의 8.8.8.8)를 추가:

nameserver 8.8.8.8

고급 설정 및 관리

nsswitch.conf 파일

호스트가 이름 해석 시 우선순위를 결정:
- 기본값: /etc/hosts → DNS 순서로 확인
- /etc/nsswitch.conf에서 수정 가능:

hosts: files dns

캐싱(Caching)

자주 조회되는 도메인의 IP는 캐싱되어 성능 향상.

명령어	설명
ip link	네트워크 인터페이스 확인
ip addr	IP 주소 확인
ip addr add	IP 주소 추가
route 또는 ip route	라우팅 테이블 확인 및 수정
nslookup	특정 도메인의 DNS 조회
dig	상세한 DNS 정보 조회

https://blog.netim.com/en/domain-names/what-is-a-premium-domain-name-13328/

https://medium.com/swlh/domain-name-system-43d024ba1c59

리눅스 네트워크 네임스페이스란?

네임스페이스는 리눅스 시스템에서 프로세스를 격리하기 위해 사용되는 기술입니다. 특히 네트워크 네임스페이스는 컨테이너(예: Docker)에서 네트워크 격리를 구현하는 데 사용됩니다.네임스페이스를 쉽게 이해하기 위해, 이를 집과 방으로 비유할 수 있습니다:

호스트 시스템은 집 전체에 해당합니다.
네임스페이스는 집 안의 방에 해당하며, 각 방은 독립적인 공간을 제공합니다.
각 방(네임스페이스)에 있는 사람(프로세스)은 자기 방 안에서만 활동을 볼 수 있고, 다른 방의 활동은 보이지 않습니다.
부모(호스트)는 모든 방을 관찰하고 관리할 수 있습니다.

네트워크 네임스페이스는 이러한 개념을 네트워크에 적용하여 컨테이너가 호스트의 네트워크 정보를 보거나 접근하지 못하도록 격리합니다.

네트워크 네임스페이스 생성 및 관리

1. 네트워크 네임스페이스 생성

리눅스에서 새로운 네트워크 네임스페이스를 생성하려면 다음 명령어를 사용합니다:

ip netns add <네임스페이스_이름>
ip netns add red
ip netns add blue

2. 네임스페이스 내 인터페이스 확인

네임스페이스 내부에서 명령어를 실행하려면 ip netns exec 명령어를 사용합니다:

ip netns exec <네임스페이스_이름> <명령어>
ip netns exec red ip link

이 명령은 해당 네임스페이스 내에서 활성화된 인터페이스만 표시합니다.

네트워크 연결 설정

1. 가상 이더넷 페어(Virtual Ethernet Pair)

두 네임스페이스 간 연결을 설정하려면 가상 이더넷 페어(Virtual Ethernet Pair)를 생성합니다. 이는 물리적 케이블처럼 작동하며, 두 끝단이 각각 다른 네임스페이스에 연결됩니다.명령어 예시:

ip link add veth-red type veth peer name veth-blue

위 명령은 veth-red와 veth-blue라는 두 인터페이스를 생성합니다.각 인터페이스를 특정 네임스페이스에 연결하려면 다음 명령을 사용합니다:

ip link set veth-red netns red
ip link set veth-blue netns blue

2. IP 주소 할당 및 활성화

각 인터페이스에 IP 주소를 할당하고 활성화해야 합니다. 예를 들어:

ip netns exec red ip addr add 192.168.15.1/24 dev veth-red
ip netns exec blue ip addr add 192.168.15.2/24 dev veth-blue

ip netns exec red ip link set veth-red up
ip netns exec blue ip link set veth-blue up

3. 핑 테스트

두 네임스페이스 간 연결을 확인하려면 핑 테스트를 수행할 수 있습니다:

ip netns exec red ping 192.168.15.2

가상 브리지(Virtual Bridge) 설정

다수의 네임스페이스가 서로 통신하도록 하려면 가상 브리지(예: Linux Bridge)를 생성해야 합니다.

1. 브리지 생성

다음 명령어로 브리지를 생성합니다:

ip link add name br0 type bridge
ip link set br0 up

2. 브리지와 네임스페이스 연결

가상 이더넷 페어의 한쪽 끝을 브리지에 연결합니다:

ip link set veth-red-br master br0
ip link set veth-blue-br master br0

ip link set veth-red-br up
ip link set veth-blue-br up

외부와의 연결

1. NAT 설정

네임스페이스 내부에서 외부 네트워크(예: 인터넷)에 접근하려면 NAT(Network Address Translation)를 설정해야 합니다. 이는 iptables 명령어로 수행됩니다:

iptables -t nat -A POSTROUTING -s 192.168.15.0/24 -o eth0 -j MASQUERADE

2. 기본 게이트웨이 추가

각 네임스페이스의 라우팅 테이블에 기본 게이트웨이를 추가하여 외부로 나가는 트래픽을 호스트로 전달합니다:

ip netns exec red ip route add default via 192.168.15.5

외부에서 내부로의 접근

외부 호스트가 특정 네임스페이스에 접근하도록 하려면 포트 포워딩을 설정해야 합니다:

iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 192.168.15.2:80
iptables -A FORWARD -p tcp -d 192.168.15.2 --dport 80 -j ACCEPT

이 설정은 호스트의 포트 8080으로 들어오는 요청을 blue 네임스페이스의 포트 80으로 전달합니다. 위 과정을 통해 리눅스 시스템에서 네트워크 격리를 구현하고, 컨테이너 또는 가상 환경 간 통신 및 외부 연결을 설정할 수 있습니다.

While testing the Network Namespaces, if you come across issues where you can't ping one namespace from the other, make sure you set the NETMASK while setting IP Address. ie: 192.168.1.10/24

ip -n red addr add 192.168.1.10/24 dev veth-red

Another thing to check is FirewallD/IP Table rules. Either add rules to IP Tables to allow traffic from one namespace to another. Or disable IP Tables all together (Only in a learning environment).

네트워크 네임스페이스를 테스트하는 동안 한 네임스페이스에서 다른 네임스페이스로 **핑(ping)**이 작동하지 않는 문제가 발생할 경우, 다음 사항들을 확인해야 합니다:

넷마스크 설정 확인
IP 주소를 설정할 때 반드시 넷마스크를 포함해야 합니다. 예를 들어, 아래 명령어처럼 /24와 같은 넷마스크를 추가하세요:

ip -n red addr add 192.168.1.10/24 dev veth-red

넷마스크가 없으면 네임스페이스 간 통신이 제대로 이루어지지 않을 수 있습니다.
FirewallD 또는 IP 테이블(IP Tables) 규칙 확인
네임스페이스 간의 트래픽을 허용하려면 방화벽 규칙을 설정하거나, 학습 환경에서만 방화벽을 비활성화할 수 있습니다:
- IP 테이블 규칙 추가: 네임스페이스 간 트래픽을 허용하는 규칙을 추가합니다.
- IP 테이블 비활성화: 학습 환경에서는 IP 테이블을 완전히 비활성화하여 문제를 해결할 수 있습니다.

1. 환경 준비

리눅스 기반 가상 머신을 준비합니다 (예: Ubuntu, CentOS 등).
iproute2 패키지가 설치되어 있는지 확인하세요 (ip 명령어 사용).
관리자 권한 (sudo)으로 작업을 진행합니다.

2. 네트워크 네임스페이스 생성

새로운 네임스페이스를 생성합니다:

ip netns add red
ip netns add blue
ip netns list
#각 인터페이스를 네임스페이스에 ㅇ녀결
ip link set veth-red netns red
ip link set veth-blue netns blue

4. IP 주소 할당 및 인터페이스 활성화

각 네임스페이스 내에서 IP 주소를 설정하고 인터페이스를 활성화합니다:

Red 네임스페이스

ip netns exec red ip addr add 192.168.15.1/24 dev veth-red
ip netns exec red ip link set veth-red up
ip netns exec red ip link set lo up

Blue 네임스페이스

ip netns exec blue ip addr add 192.168.15.2/24 dev veth-blue
ip netns exec blue ip link set veth-blue up
ip netns exec blue ip link set lo up

5. 연결 테스트

red 네임스페이스에서 blue 네임스페이스로 핑 테스트를 수행합니다:

ip netns exec red ping 192.168.15.2

다수의 네임스페이스 연결 (가상 브리지 사용)

여러 네임스페이스 간 통신을 위해 가상 브리지를 설정합니다.

가상 브리지 생성

ip link add name br0 type bridge
ip link set br0 up

브리지와 네임스페이스 연결

각 네임스페이스에 새로운 가상 이더넷 페어를 생성하고, 한쪽 끝을 브리지에 연결합니다.

Red 네임스페이스:

ip link add veth-red-br type veth peer name veth-red-vr
ip link set veth-red-br netns red
ip link set veth-red-vr master br0
ip link set veth-red-vr up

ip netns exec red ip addr add 192.168.15.1/24 dev veth-red-br
ip netns exec red ip link set veth-red-br up

Blue 네임스페이스:

ip link add veth-blue-br type veth peer name veth-blue-vr
ip link set veth-blue-br netns blue
ip link set veth-blue-vr master br0
ip link set veth-blue-vr up

ip netns exec blue ip addr add 192.168.15.2/24 dev veth-blue-br
ip netns exec blue ip link set veth-blue-br up

외부 네트워크와의 연결 (NAT 설정)

네임스페이스가 외부 인터넷에 접근하려면 NAT(Network Address Translation)를 설정해야 합니다.

IP 테이블 NAT 규칙 추가

호스트에서 다음 명령어를 실행하여 NAT를 활성화합니다:

iptables -t nat -A POSTROUTING -s 192.168.15.0/24 -o eth0 -j MASQUERADE

기본 게이트웨이 설정

각 네임스페이스에 기본 게이트웨이를 추가합니다 (호스트의 브리지 IP 사용):

ip netns exec red ip route add default via 192.168.15.5
ip netns exec blue ip route add default via 192.168.15.5

외부에서 내부로의 접근 (포트 포워딩)

외부에서 특정 네임스페이스로 접근하려면 포트 포워딩을 설정합니다:

iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 192.168.15.2:80
iptables -A FORWARD -p tcp -d 192.168.15.2 --dport 80 -j ACCEPT

이 설정은 호스트의 포트 8080으로 들어오는 요청을 blue 네임스페이스의 포트 80으로 전달

Storage - Container Storage Interface (CSI)

궁굼하다 — Mon, 13 Jan 2025 23:00:02 +0900

https://inspirit941.tistory.com/412

컨테이너 스토리지 인터페이스 (CSI)

배경

과거에는 Kubernetes가 컨테이너 런타임 엔진으로 Docker만 사용했습니다. 이때 Kubernetes 소스 코드에 Docker와 관련된 모든 코드가 포함되어 있었습니다. 그러나 RKT, CRI-O와 같은 다른 컨테이너 런타임이 등장하면서, Kubernetes는 다양한 컨테이너 런타임을 지원할 수 있도록 확장될 필요가 있었습니다. 이를 위해 **컨테이너 런타임 인터페이스(Container Runtime Interface, CRI)**가 도입되었습니다.

CRI는 Kubernetes와 Docker 같은 컨테이너 런타임 간의 통신 방법을 표준화한 규격입니다.
새로운 컨테이너 런타임이 개발되더라도 CRI 표준만 따르면 Kubernetes와 호환될 수 있습니다.
이는 Kubernetes 소스 코드를 수정하거나 Kubernetes 개발팀과 협력할 필요 없이 가능합니다.

비슷한 방식으로, 네트워킹 솔루션을 확장하기 위해 **컨테이너 네트워킹 인터페이스(Container Networking Interface, CNI)**가 도입되었습니다. CNI 표준을 따르면 새로운 네트워킹 플러그인을 Kubernetes와 쉽게 통합할 수 있습니다.

CSI의 등장

마찬가지로, 다양한 스토리지 솔루션을 지원하기 위해 **컨테이너 스토리지 인터페이스(Container Storage Interface, CSI)**가 개발되었습니다.

CSI를 통해 각 스토리지 벤더는 자신의 드라이버를 작성하여 Kubernetes와 연동할 수 있습니다.
예: Portworx, Amazon EBS, Azure Disk, Dell EMC Isilon, NetApp, Nutanix 등 다양한 스토리지 벤더들이 CSI 드라이버를 제공합니다.
중요한 점은 CSI가 Kubernetes 전용 표준이 아니라는 것입니다. 이는 범용 표준으로 설계되었으며, 이를 구현하면 Kubernetes뿐만 아니라 Cloud Foundry, Mesos 같은 다른 컨테이너 오케스트레이션 도구에서도 작동할 수 있습니다.

CSI의 작동 방식

CSI는 컨테이너 오케스트레이터(예: Kubernetes)와 스토리지 드라이버 간의 통신을 위한 일련의 **RPC(Remote Procedure Calls)**를 정의합니다. 스토리지 드라이버는 이 RPC를 구현하여 요청을 처리해야 합니다.

주요 RPC 예시

볼륨 생성 (Create Volume)
- Pod가 생성되면서 볼륨을 요구하면, Kubernetes는 CreateVolume RPC를 호출합니다.
- 이 호출에는 볼륨 이름 등의 세부 정보가 포함됩니다.
- 스토리지 드라이버는 이 요청을 처리하여 스토리지 배열에 새 볼륨을 프로비저닝(provisioning)하고 결과를 반환합니다.
볼륨 삭제 (Delete Volume)
- 볼륨이 삭제될 때 Kubernetes는 DeleteVolume RPC를 호출합니다.
- 스토리지 드라이버는 이 요청에 따라 스토리지 배열에서 해당 볼륨을 해제(decommissioning)해야 합니다.

CSI 명세

CSI 명세는 다음 사항들을 정확히 정의합니다:

호출자가 전달해야 할 매개변수
솔루션(스토리지 드라이버)이 반환해야 할 값
교환되어야 할 오류 코드

요약

CSI는 다양한 스토리지 솔루션과 컨테이너 오케스트레이션 도구 간의 호환성을 보장하는 범용 표준입니다.
이를 통해 새로운 스토리지 솔루션도 쉽게 Kubernetes 및 기타 플랫폼과 통합될 수 있습니다.
CSI 명세는 GitHub에서 확인할 수 있으며, 세부적인 구현 내용은 명세에 따라 이루어집니다.

Kubernetes 외에도 Cloud Foundry와 Mesos가 CSI를 지원하고 있습니다.

https://kubernetes.io/ko/docs/concepts/storage/storage-classes/

https://kubernetes.io/ko/docs/concepts/storage/volumes/

https://kubernetes.io/ko/docs/concepts/storage/persistent-volumes/

https://tech.gluesys.com/blog/2022/06/21/CSI.html

Volume

1. 컨테이너와 데이터의 휘발성

컨테이너는 일시적인 존재로, 필요한 작업을 처리한 뒤 삭제됩니다.
컨테이너가 삭제되면 내부에 저장된 데이터도 함께 사라집니다.
데이터를 유지하려면 **볼륨(Volume)**이라는 저장 공간을 컨테이너에 연결해야 합니다.
- 볼륨은 컨테이너 외부에 데이터를 저장하므로, 컨테이너가 삭제되어도 데이터는 유지됩니다.

2. 쿠버네티스에서의 볼륨

쿠버네티스에서도 Pod(컨테이너를 묶은 단위)는 일시적입니다.
Pod가 삭제되면 그 안에서 생성된 데이터도 사라집니다.
이를 해결하기 위해 Pod에 볼륨을 연결합니다.
- 볼륨에 저장된 데이터는 Pod가 삭제되어도 유지됩니다.

3. 볼륨의 간단한 예제

Pod 생성 및 데이터 처리
- 예제: 랜덤 숫자를 생성해 /opt/number.out 파일에 저장하는 Pod를 만듭니다.
- 문제: Pod가 삭제되면 이 파일과 숫자도 사라집니다.
볼륨 추가로 데이터 유지
- 볼륨을 생성하고, 이를 Pod에 연결합니다.
- 볼륨은 호스트(서버)의 특정 디렉터리(예: /data)를 사용하도록 설정합니다.
- Pod 내부의 디렉터리(/opt)와 호스트의 /data 디렉터리를 연결하면, Pod가 삭제되더라도 /data에 데이터가 남아 있습니다.

4. 볼륨 구성 방법

볼륨은 다양한 방식으로 저장소를 설정할 수 있습니다.

1) HostPath (호스트 경로)

호스트 서버의 특정 디렉터리(예: /data)를 사용하여 데이터를 저장합니다.
단점: 여러 노드(서버)가 있는 클러스터에서는 비추천입니다.
- 각 노드의 /data 디렉터리가 서로 다르기 때문에 동일한 데이터를 보장할 수 없습니다.

2) 외부 스토리지 솔루션

쿠버네티스는 다양한 스토리지 솔루션을 지원합니다:
- NFS, CephFS, Flocker 등 네트워크 스토리지
- 퍼블릭 클라우드 스토리지:
  - AWS EBS (Elastic Block Store)
  - Azure Disk
  - Google Persistent Disk
- 고급 스토리지 시스템:
  - Fiber Channel, ScaleIO 등

3) AWS EBS 예제

AWS EBS를 볼륨으로 사용하려면 다음과 같이 설정합니다:

volumes:
  - name: my-volume
    awsElasticBlockStore:
      volumeID: "vol-0abcd1234efgh5678"
      fsType: "ext4"

이렇게 하면 AWS EBS에 데이터가 저장됩니다.

5. 요약

쿠버네티스에서 Pod와 데이터는 기본적으로 일시적입니다.
데이터를 유지하려면 볼륨을 생성하고 Pod에 연결해야 합니다.
여러 종류의 스토리지 옵션이 있으며, 필요에 따라 적합한 것을 선택합니다:
- 단일 노드에서는 HostPath,
- 다중 노드 또는 클라우드 환경에서는 NFS, AWS EBS 등의 외부 스토리지를 권장합니다.

초등학생을 위한 쉬운 설명

컴퓨터 안의 상자(Pod)가 일을 하고 숫자를 만들어요.
그런데 상자가 없어지면 숫자도 사라져요!
그래서 상자 옆에 가방(볼륨)을 두고 숫자를 가방에 넣어요.
상자가 없어져도 가방은 남아 있으니까 숫자가 안전해요!

1. 볼륨과 퍼시스턴트 볼륨의 차이

이전 강의에서 배운 **볼륨(Volume)**은 Pod 안에 정의되며, Pod가 삭제되면 데이터도 함께 사라질 수 있었습니다.
하지만, **퍼시스턴트 볼륨(Persistent Volume)**은 클러스터 전체에서 사용할 수 있는 중앙화된 저장소입니다.
- 관리자가 미리 큰 저장소 풀(pool)을 만들어 놓습니다.
- 사용자는 이 저장소에서 필요한 만큼만 가져다 쓸 수 있습니다.

왜 퍼시스턴트 볼륨이 필요할까요?

많은 사용자가 여러 Pod를 배포하는 환경에서는, 매번 각 Pod에 저장소를 설정하는 것이 번거롭습니다.
중앙에서 저장소를 관리하면:
- 사용자는 간단히 필요한 저장소를 요청해서 사용할 수 있습니다.
- 관리자는 전체 저장소를 효율적으로 관리할 수 있습니다.

2. 퍼시스턴트 볼륨 만들기

기본 템플릿

퍼시스턴트 볼륨을 생성하려면 다음과 같은 YAML 파일을 작성합니다:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-vol1
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 1Gi
  hostPath:
    path: "/data"

주요 구성 요소

apiVersion과 kind
- apiVersion: API 버전을 지정합니다. 여기서는 v1을 사용합니다.
- kind: 리소스 종류를 지정합니다. 여기서는 PersistentVolume입니다.
metadata
- 퍼시스턴트 볼륨의 이름을 지정합니다. 예: pv-vol1.
spec (세부 설정)
- accessModes (접근 모드):
  - 볼륨이 어떻게 사용될지 정의합니다.
  - 주요 옵션:
    - ReadWriteOnce: 하나의 노드에서 읽기/쓰기 가능.
    - ReadOnlyMany: 여러 노드에서 읽기만 가능.
    - ReadWriteMany: 여러 노드에서 읽기/쓰기 가능.
- capacity (용량):
  - 이 볼륨에 할당된 저장 공간 크기를 지정합니다. 예: 1Gi (1GB).
- hostPath (저장소 경로):
  - 로컬 디렉터리를 저장소로 사용합니다. 예: /data.
  - 주의: 이 옵션은 테스트 환경에서만 사용하고, 실제 운영 환경에서는 적합하지 않습니다.

3. 퍼시스턴트 볼륨 생성 및 확인

명령어 실행

YAML 파일을 작성한 뒤, 다음 명령어로 퍼시스턴트 볼륨을 생성합니다

kubectl create -f pv.yaml
kubectl get persistentvolume

4. 퍼시스턴트 볼륨의 다양한 스토리지 옵션

이전 강의에서 배운 것처럼, 여러 스토리지 솔루션을 사용할 수 있습니다.
- 로컬 디렉터리(hostPath) 외에도 다음과 같은 옵션이 있습니다:
  - AWS EBS (Elastic Block Store)
  - Azure Disk
  - Google Persistent Disk
  - NFS (Network File System)
  - CephFS 등

예: AWS EBS를 사용하는 경우

spec:
  awsElasticBlockStore:
    volumeID: "vol-0abcd1234efgh5678"
    fsType: "ext4"

5. 초등학생을 위한 쉬운 설명

쿠버네티스는 여러 사람이 컴퓨터를 나눠 쓰는 놀이터라고 생각해보세요!
놀이터에 있는 장난감(Pod)이 데이터를 만들어내는데, 이 데이터를 잃어버리지 않으려면 가방(볼륨)이 필요했죠?
그런데 사람들이 많아지면 각자 가방을 준비하기가 너무 힘들어요!
그래서 놀이터 관리자(관리자)가 큰 창고(퍼시스턴트 볼륨)를 만들어 놓고, 필요한 사람에게 조금씩 나눠주는 거예요.
이제 사람들은 창고에서 필요한 만큼 가져다 쓰면 돼요!

6. 요약

퍼시스턴트 볼륨은 클러스터 전체에서 사용할 수 있는 중앙화된 저장소입니다.
관리자가 미리 큰 저장소를 만들어 놓으면, 사용자는 간단히 요청해서 사용할 수 있습니다.
다양한 스토리지 솔루션과 연동 가능하며, 운영 환경에서는 AWS EBS나 NFS 같은 외부 스토리지를 권장합니다.

Persistent Volume(PV)와 Persistent Volume Claim(PVC)란?

Persistent Volume(PV): 저장 공간이에요. 선생님(관리자)이 미리 만들어 둔 큰 상자라고 생각하면 돼요.
Persistent Volume Claim(PVC): 학생(사용자)이 "이만큼 공간이 필요해요!"라고 요청하는 메모지예요.

PVC를 사용하면 필요한 만큼 저장 공간을 가져다 쓸 수 있어요. Kubernetes는 PVC를 보고 알맞은 크기의 PV를 찾아서 연결해줘요.

PVC가 어떻게 작동하나요?

선생님(관리자)이 여러 개의 PV(저장 상자)를 준비해 둡니다.
학생(사용자)은 PVC를 작성해서 "저는 500MB가 필요해요!"라고 요청합니다.
Kubernetes는 PVC를 읽고, 조건에 맞는 PV를 찾아 연결합니다.
- 예: 요청한 크기(500MB), 접근 방식(ReadWriteOnce 등), 저장소 종류(Storage Class) 등을 확인합니다.
만약 조건에 맞는 PV가 없으면, PVC는 대기 상태에 머물러 있어요. 새로운 PV가 생기면 자동으로 연결됩니다.

중요한 특징

1:1 관계: 하나의 PVC는 하나의 PV만 사용할 수 있어요. 남은 공간은 다른 사람이 쓸 수 없어요.
작은 요청, 큰 상자: 요청한 크기보다 큰 PV가 있으면, 그 상자를 사용할 수도 있어요.
대기 상태: 조건에 맞는 PV가 없으면 PVC는 기다립니다.

PVC 만들기

PVC를 만들 때는 다음과 같이 설정해요:

이름: "My Claim"
접근 모드: ReadWriteOnce (읽고 쓰기 가능)
요청 크기: 500MB

PVC를 만들고 나면, Kubernetes가 자동으로 알맞은 PV를 찾아 연결합니다. 예를 들어, 1GB 크기의 PV가 있다면, 500MB 요청도 그 상자에 연결될 수 있어요.

PVC 삭제 시 발생하는 일

PVC를 삭제하면 PV에는 세 가지 옵션이 있어요:

유지(Retain): PV는 그대로 남아 있고, 관리자만 삭제할 수 있어요.
삭제(Delete): PVC가 삭제되면 PV도 자동으로 삭제돼요.
재활용(Recycle): 기존 데이터를 삭제하고 다른 사용자가 다시 쓸 수 있도록 준비돼요.

정리

PV: 저장 공간 (큰 상자)
PVC: 저장 공간 요청 (메모지)
PVC와 PV는 1:1로 연결돼요.
PVC 삭제 후에는 데이터를 유지하거나 삭제하거나 재활용할 수 있어요.

https://www.linkedin.com/pulse/complete-guide-understanding-persistent-volume-claim-pvc-arya-soni/

https://support.huaweicloud.com/intl/en-us/basics-cce/kubernetes_0030.html

Kubernetes Persistent Volume (PV)와 Persistent Volume Claim (PVC) 예시

Kubernetes에서 **Persistent Volume (PV)**는 클러스터의 저장소 자원을 나타내며, **Persistent Volume Claim (PVC)**는 사용자가 특정 저장소를 요청하는 객체입니다. 아래는 PV와 PVC를 설정하고 사용하는 예시를 YAML 파일과 함께 단계별로 설명합니다.

1. Persistent Volume (PV) 생성

먼저, 클러스터에 저장소를 정의하는 PV를 생성합니다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual
  hostPath:
    path: /mnt/data

capacity: 10Gi(기가바이트)의 저장 공간을 제공합니다.
accessModes: ReadWriteOnce로 설정하여 하나의 노드에서 읽기/쓰기 가능하도록 합니다.
persistentVolumeReclaimPolicy: Retain으로 설정하여 PVC가 삭제되더라도 PV는 유지됩니다.
hostPath: /mnt/data 경로를 로컬 스토리지로 사용합니다.

2. Persistent Volume Claim (PVC) 생성

PVC를 생성하여 위에서 만든 PV를 요청합니다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: manual

accessModes: ReadWriteOnce로 설정하여 PVC가 PV와 동일한 접근 모드를 요구합니다.
resources.requests.storage: 5Gi의 저장 공간을 요청합니다. PV의 크기(10Gi)가 요청 크기(5Gi)보다 크므로 바인딩이 가능합니다.
storageClassName: manual로 설정하여 동일한 스토리지 클래스를 사용하는 PV와 매칭됩니다.

3. PVC와 PV 바인딩 확인

PVC가 PV에 성공적으로 바인딩되었는지 확인합니다.

kubectl get pvc
NAME          STATUS   VOLUME       CAPACITY   ACCESS MODES   STORAGECLASS   AGE
example-pvc   Bound    example-pv   10Gi       RWO            manual         2m

4. Pod에서 PVC 사용

PVC를 Pod에 연결하여 데이터를 저장할 수 있도록 합니다.

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: nginx-container
      image: nginx
      volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: storage-volume
  volumes:
    - name: storage-volume
      persistentVolumeClaim:
        claimName: example-pvc

volumeMounts.mountPath: 컨테이너 내부에서 /usr/share/nginx/html 경로에 PVC를 마운트합니다.
volumes.persistentVolumeClaim.claimName: 앞서 생성한 PVC(example-pvc)를 참조합니다.

6. PVC 삭제 시 동작

PVC 삭제 후 PV의 동작은 persistentVolumeReclaimPolicy에 따라 달라집니다:

Retain (유지):
- PVC 삭제 후에도 PV는 유지됩니다.
- 관리자가 수동으로 삭제해야 합니다.
Delete (삭제):
- PVC 삭제 시 PV도 자동으로 삭제됩니다.
Recycle (재활용):
- 데이터가 삭제된 후 다른 PVC에서 재사용 가능합니다.

Once you create a PVC use it in a POD definition file by specifying the PVC Claim name under persistentVolumeClaim section in the volumes section like this:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

The same is true for ReplicaSets or Deployments. Add this to the pod template section of a Deployment on ReplicaSet.

https://kubernetes.io/docs/concepts/storage/persistent-volumes/#claims-as-volumes

Persistent Volumes

This document describes persistent volumes in Kubernetes. Familiarity with volumes, StorageClasses and VolumeAttributesClasses is suggested. Introduction Managing storage is a distinct problem from managing compute instances. The PersistentVolume subsystem

kubernetes.io

The application stores logs at location /log/app.log. View the logs.

You can exec in to the container and open the file:

kubectl exec webapp -- cat /log/app.log
[2025-01-13 13:18:44,494] INFO in event-simulator: USER2 logged out
[2025-01-13 13:18:45,495] INFO in event-simulator: USER1 is viewing page3
[2025-01-13 13:18:46,495] INFO in event-simulator: USER1 logged out
[2025-01-13 13:18:47,496] INFO in event-simulator: USER4 is viewing page1
[2025-01-13 13:18:48,497] INFO in event-simulator: USER3 logged in
[2025-01-13 13:18:49,498] WARNING in event-simulator: USER5 Failed to Login as the account is locked due to MANY FAILED ATTEMPTS.
[2025-01-13 13:18:49,499] INFO in event-simulator: USER2 is viewing page3
[2025-01-13 13:18:50,500] INFO in event-simulator: USER4 logged in
[2025-01-13 13:18:51,501] INFO in event-simulator: USER4 logged in
[2025-01-13 13:18:52,502] WARNING in event-simulator: USER7 Order failed as the item is OUT OF STOCK.
[2025-01-13 13:18:52,503] INFO in event-simulator: USER4 is viewing page3

Configure a volume to store these logs at /var/log/webapp on the host.

Use the spec provided below.

Name: webapp
Image Name: kodekloud/event-simulator
Volume HostPath: /var/log/webapp
Volume Mount: /log

k edit pod webapp

## 볼륨 추가
 volumes:
  - name: log-volume
    hostPath:
      path: /var/log/webapp
      
## 볼륨마운트 추가
volumeMounts:
    - mountPath: /log
      name: log-volume

Create a Persistent Volume with the given specification.

Volume Name: pv-log

Storage: 100Mi

Access Modes: ReadWriteMany

Host Path: /pv/log

Reclaim Policy: Retain

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-log
spec:
  capacity:
    storage: 100Mi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /pv/log

Let us claim some of that storage for our application. Create a Persistent Volume Claim with the given specification.

Persistent Volume Claim: claim-log-1

Storage Request: 50Mi

Access Modes: ReadWriteOnce

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim-log-1
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Mi

Update the webapp pod to use the persistent volume claim as its storage.

Replace hostPath configured earlier with the newly created PersistentVolumeClaim.

https://waspro.tistory.com/580

https://nice-engi neer.tistory.com/entry/Kubernetes-Object-Volume%EC%9D%B4%EB%9E%80-2

[Kubernetes] Object - Volume이란 (2)

✔️ Network 볼륨 (Persistent Storage) Pod 내부에서 특정 데이터를 보유해야 하는 stateful한(ex. DB) app의 경우 stateless한(Pod, deployment) 데이터를 영속적으로 저장하기 위한 방법이 필요하다. Pod에서 실행

nice-engineer.tistory.com

## pv 정의
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 2Gi # 스토리지 용량
  volumeMode: Filesystem # 파일 시스템 형식
  accessModes:
    - ReadWriteOnce # 하나의 노드만 읽기/쓰기 가능
  persistentVolumeReclaimPolicy: Retain # PV 반환 정책
  hostPath:
    path: /data/pv-example # 클러스터 노드의 경로

## pvc정의
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-example
spec:
  accessModes:
    - ReadWriteOnce # 읽기/쓰기 접근 모드
  volumeMode: Filesystem # 파일 시스템 형식
  resources:
    requests:
      storage: 1Gi # 요청한 용량

### pod
apiVersion: v1
kind: Pod
metadata:
  name: pod-example
spec:
  containers:
    - name: app-container
      image: nginx # 컨테이너 이미지
      volumeMounts:
        - name: app-storage
          mountPath: /usr/share/nginx/html # 컨테이너 내부 경로
  volumes:
    - name: app-storage
      persistentVolumeClaim:
        claimName: pvc-example # 참조할 PVC 이름

Storage - Introduction to Docker Storage

궁굼하다 — Mon, 13 Jan 2025 20:00:12 +0900

https://inspirit941.tistory.com/412

CKA 대비 kubernetes 스터디 - 7. Storage

Docker Storage 크게 두 가지 개념이 있다. Storage Driver docker는 데이터를 어디에 저장하는지, container에서 fileSystem을 어떻게 관리하는지. docker image를 실행하면, /var/lib/docker 라는 경로를 컨테이너 내부

inspirit941.tistory.com

https://velog.io/@zuckerfrei/Storage-in-Docker

https://blog.knoldus.com/unionfs-a-file-system-of-a-container/

Tale of a Container's File System

Namespace, CGroup, and Union file-system are the basic building blocks of a container. Let's have our focus on file-system. Why yet another file-system for the

blog.knoldus.com

도커란 무엇인가요?

도커는 컴퓨터에서 프로그램(소프트웨어)을 실행하기 위해 필요한 모든 것을 한 곳에 담아주는 **"컨테이너"**라는 기술을 사용하는 도구입니다. 이 컨테이너는 마치 작은 상자처럼, 프로그램이 잘 작동하도록 필요한 파일과 설정을 모두 담고 있어요. 그래서 어디서든 똑같이 실행될 수 있답니다!

도커가 데이터를 저장하는 방법

도커는 컴퓨터 안에 특별한 폴더를 만들어 데이터를 저장해요. 이 폴더는 보통 /var/lib/docker/라는 위치에 있습니다. 여기에는 다음과 같은 것들이 저장돼요:

이미지(Image): 프로그램을 실행하기 위해 필요한 기본 파일들.
컨테이너(Container): 이미지를 기반으로 실제로 실행되는 프로그램.
볼륨(Volume): 컨테이너가 사용하는 데이터(예: 저장해야 하는 파일들).

이미지와 컨테이너의 차이

이미지는 요리책처럼 프로그램을 실행하기 위한 "설명서"입니다. 예를 들어, "우분투(Ubuntu)"라는 운영체제를 기반으로 하고, 그 위에 파이썬(Python)이라는 프로그램을 설치하는 식으로 단계별로 만들어져요.
컨테이너는 이미지를 사용해 실제로 실행되는 프로그램이에요. 요리책대로 요리를 만든 음식이라고 생각하면 돼요.

이미지의 층(layer) 구조

도커의 이미지는 여러 층으로 이루어져 있어요. 마치 샌드위치처럼 각 층마다 다른 내용물이 들어있죠:

첫 번째 층: 기본 운영체제(예: 우분투).
두 번째 층: 필요한 프로그램 설치(예: 파이썬).
세 번째 층: 소스 코드 추가(예: 우리가 만든 프로그램).

각 층은 이전 층에서 달라진 부분만 저장하기 때문에 공간을 절약할 수 있어요.

컨테이너의 읽기/쓰기 구조

컨테이너는 이미지를 기반으로 실행되는데, 이미지 자체는 수정할 수 없어요(읽기 전용). 대신, 컨테이너 위에 새로운 쓰기 가능한 층이 추가돼요. 이 층은 다음과 같은 데이터를 저장합니다:

로그 파일(프로그램 작동 기록).
임시로 생성된 파일들.

하지만 컨테이너가 삭제되면 이 데이터도 함께 사라져요.

데이터를 영구적으로 저장하려면?

컨테이너가 삭제돼도 데이터를 보존하려면 **볼륨(volume)**이라는 기능을 사용해요. 볼륨은 컴퓨터의 특정 폴더를 컨테이너와 연결해 데이터를 안전하게 저장할 수 있게 해줍니다.

https://velog.io/@zuckerfrei/Storage-in-Docker

볼륨 사용 방법

볼륨 생성: docker volume create [볼륨 이름]
컨테이너와 연결: docker run -v [볼륨 이름]:[컨테이너 내부 경로]

스토리지 드라이버(Storage Driver)

도커가 이런 구조를 관리할 수 있도록 도와주는 것이 바로 스토리지 드라이버입니다. 운영체제에 따라 적합한 드라이버가 자동으로 선택됩니다:

예: 우분투에서는 AUFS, CentOS에서는 Device Mapper 등이 사용돼요.

요약

도커는 프로그램을 쉽게 실행하고 관리할 수 있도록 도와주는 도구입니다. 이미지는 읽기 전용이고, 컨테이너는 실행 중 데이터를 쓸 수 있어요. 데이터를 영구적으로 저장하려면 볼륨을 사용하면 됩니다!\

강의 내용 요약

스토리지 드라이버(Storage Drivers)
- 스토리지 드라이버는 이미지와 컨테이너의 스토리지를 관리하는 역할을 한다.
- 하지만 데이터를 **영구적으로 저장(persist storage)**하려면 **볼륨(Volumes)**을 생성해야 한다.
볼륨(Volumes)
- 볼륨은 스토리지 드라이버가 아닌 **볼륨 드라이버 플러그인(Volume Driver Plugins)**에 의해 처리된다.
- 기본 볼륨 드라이버 플러그인은 local이다.
  - local 볼륨 플러그인은 Docker 호스트에 볼륨을 생성하고 데이터를 /var/lib/docker/volumes 디렉토리에 저장한다.
- 다양한 서드파티 솔루션을 지원하는 여러 볼륨 드라이버 플러그인이 존재한다:
  - 예: Azure File Storage, Convoy, DigitalOcean Block Storage, Flocker, Google Compute Persistent Disks, Cluster FS, NetApp, REX-Ray, Portworx, VMware vSphere Storage 등.
REX-Ray와 같은 특정 볼륨 드라이버
- REX-Ray는 다양한 스토리지 제공자를 지원한다:
  - AWS EBS (Elastic Block Store), S3
  - EMC 스토리지 어레이 (Isilon, ScaleIO)
  - Google Persistent Disk
  - OpenStack Cinder 등
- 예를 들어, Docker 컨테이너를 실행할 때 REX-Ray EBS를 사용하여 Amazon EBS에서 볼륨을 프로비저닝(provision)할 수 있다.
  - 이 경우 컨테이너가 종료되더라도 데이터는 AWS 클라우드에 안전하게 저장된다.
다음 강의 예고
- 이후 강의에서는 Kubernetes에서의 볼륨 관리에 대해 더 자세히 다룰 예정이다.

스토리지 드라이버(Storage Drivers)
스토리지 드라이버는 도커(Docker) 이미지와 컨테이너의 데이터를 관리하기 위한 핵심 구성 요소입니다. 그러나 컨테이너의 데이터는 기본적으로 컨테이너가 종료되면 사라지기 때문에 데이터를 영구적으로 저장하려면 **볼륨(Volume)**을 사용해야 합니다.
볼륨(Volumes)과 볼륨 드라이버 플러그인
도커에서 볼륨은 데이터를 영구적으로 저장하기 위한 메커니즘입니다. 하지만 볼륨은 스토리지 드라이버가 아니라 별도의 볼륨 드라이버 플러그인에 의해 관리됩니다.
- 기본적으로 도커는 local이라는 기본 볼륨 드라이버 플러그인을 제공합니다. 이 플러그인은 도커 호스트(컨테이너가 실행 중인 서버)에 볼륨을 생성하며, 생성된 데이터는 /var/lib/docker/volumes 디렉토리에 저장됩니다.
- 하지만 많은 경우 클라우드나 외부 스토리지 솔루션과 통합하여 데이터를 저장할 필요가 있습니다. 이를 위해 여러 서드파티 볼륨 드라이버 플러그인이 제공됩니다:
  - 예: Azure File Storage, DigitalOcean Block Storage, Google Compute Persistent Disks 등.
REX-Ray와 같은 고급 볼륨 드라이버
REX-Ray는 AWS EBS(Amazon Elastic Block Store), S3(Simple Storage Service), Google Persistent Disk 등 다양한 클라우드 및 온프레미스 스토리지를 지원합니다.예를 들어, 도커 컨테이너를 실행할 때 REX-Ray EBS를 사용하여 Amazon EBS에서 새로운 볼륨을 생성하고 이를 컨테이너에 연결할 수 있습니다. 이렇게 하면 컨테이너가 종료되더라도 데이터는 Amazon EBS에 안전하게 저장됩니다.
Kubernetes와의 연계
이후 강의에서는 Kubernetes에서의 볼륨 관리와 스토리지 통합 방법에 대해 다룰 예정입니다. Kubernetes는 도커보다 복잡한 환경에서 스토리지를 관리하기 위해 설계된 추가 기능들을 제공합니다.

핵심 정리

도커에서 데이터를 영구적으로 유지하려면 볼륨을 사용해야 하며, 이는 볼륨 드라이버 플러그인으로 관리된다.
기본 플러그인은 local이며, 서드파티 플러그인을 통해 다양한 클라우드 및 외부 스토리지를 활용할 수 있다.
REX-Ray와 같은 고급 플러그인은 AWS EBS, Google Persistent Disk 등 여러 스토리지 제공자를 지원한다.
Kubernetes 환경에서도 이러한 개념은 확장되어 적용된다.

Secrets test/Encrypting Confidential Data at Rest

궁굼하다 — Thu, 9 Jan 2025 10:30:16 +0900

The reason the application is failed is because we have not created the secrets yet. Create a new secret named db-secret with the data given below.

You may follow any one of the methods discussed in lecture to create the secret.

Secret Name: db-secret
Secret 1: DB_Host=sql01
Secret 2: DB_User=root
Secret 3: DB_Password=password123

kubectl create secret generic --help
# Create a new secret named my-secret with key1=supersecret and key2=topsecret
kubectl create secret generic my-secret --from-literal=key1=supersecret --from-literal=key2=topsecret

k create secret generic db-secret --from-literal=DB_host=sql01 --from-literal=DB_User=root --from-literal=DB_Password=password123

Configure webapp-pod to load environment variables from the newly created secret.

apiVersion: v1
kind: Pod
metadata:
  name: envfrom-secret
spec:
  containers:
  - name: envars-test-container
    image: nginx
    envFrom:
    - secretRef:
        name: test-secret

https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/

Distribute Credentials Securely Using Secrets

This page shows how to securely inject sensitive data, such as passwords and encryption keys, into Pods. Before you begin You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is re

kubernetes.io

https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/

Encrypting Confidential Data at Rest

All of the APIs in Kubernetes that let you write persistent API resource data support at-rest encryption. For example, you can enable at-rest encryption for Secrets. This at-rest encryption is additional to any system-level encryption for the etcd cluster

kubernetes.io

Encrypting Confidential Data at Rest

$$$ kubectl create secret generic my-secret --from-literal=key1=supersecret
secret/my-secret created

$$$ kubectl get secret my-secret -o yaml
apiVersion: v1
data:
  key1: c3VwZXJzZWNyZXQ=
kind: Secret
metadata:
  creationTimestamp: "2025-01-09T00:13:34Z"
  name: my-secret
  namespace: default
  resourceVersion: "618434"
  uid: 00fe1b20-129d-4272-aa8c-7de9e48b7bfd
type: Opaque

$$$ kubectl get secret my-secret
NAME        TYPE     DATA   AGE
my-secret   Opaque   1      35s

kubectl describe secrets my-secret
Name:         my-secret
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
key1:  11 bytes

$$$ echo "c3VwZXJzZWNyZXQ=" | base64 --decode
supersecret

ETCDCTL_API=3 etcdctl \
   --cacert=/etc/kubernetes/pki/ca.crt   \
   --cert=/etc/kubernetes/pki/server.crt \
   --key=/etc/kubernetes/pki/server.key  \
   get /registry/secrets/default/my-secret | hexdump -C

Encrypt your data

kube spray로 설치시 경로가 달라짐

etcd도 systemd 아래에 설치되어 운영됨

/etc/ssl/etcd/ssl/ 디렉토리에 있는 각 파일의 역할은 다음과 같습니다:

ca.pem:
- etcd 클러스터에서 사용하는 CA 인증서입니다.
- --cacert 옵션에 사용됩니다.
ca-key.pem:
- CA 인증서를 생성하기 위한 키 파일입니다. 일반적으로 클라이언트 명령어에는 필요하지 않습니다.
admin-master.pem:
- etcd 클러스터 관리용 클라이언트 인증서입니다.
- --cert 옵션에 사용됩니다.
admin-master-key.pem:
- admin-master.pem에 대한 개인 키입니다.
- --key 옵션에 사용됩니다.
member-master-key.pem, node-master-key.pem, 등:
- etcd 멤버 노드와 관련된 키 파일입니다. 일반적으로 클라이언트 명령어에는 필요하지 않습니다.

ETCDCTL_API=3 etcdctl   --endpoints=https://127.0.0.1:2379   --cacert=/etc/ssl/etcd/ssl/ca.pem   --cert=/etc/ssl/etcd/ssl/admin-master.pem   --key=/etc/ssl/etcd/ssl/admin-master-key.pem   get / --prefix --keys-only | head



/registry/apiextensions.k8s.io/customresourcedefinitions/bgpconfigurations.crd.projectcalico.org

/registry/apiextensions.k8s.io/customresourcedefinitions/bgpfilters.crd.projectcalico.org

/registry/apiextensions.k8s.io/customresourcedefinitions/bgppeers.crd.projectcalico.org

/registry/apiextensions.k8s.io/customresourcedefinitions/blockaffinities.crd.projectcalico.org

/registry/apiextensions.k8s.io/customresourcedefinitions/caliconodestatuses.crd.projectcalico.org
.
.
.
.
.

ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/ssl/etcd/ssl/ca.pem \
  --cert=/etc/ssl/etcd/ssl/admin-master.pem \
  --key=/etc/ssl/etcd/ssl/admin-master-key.pem \
  get /registry/secrets/default/my-secret | hexdump -C
00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 6d 79 2d 73 65 63  |s/default/my-sec|
00000020  72 65 74 0a 6b 38 73 3a  65 6e 63 3a 61 65 73 63  |ret.k8s:enc:aesc|
00000030  62 63 3a 76 31 3a 6b 65  79 31 3a 58 70 28 1d e4  |bc:v1:key1:Xp(..|
00000040  b7 ff 4a 79 aa f5 fb 08  b6 c7 57 e5 dd 92 04 5e  |..Jy......W....^|
00000050  a5 95 ef d7 46 96 55 c7  b9 e2 96 91 82 d4 3f 3c  |....F.U.......?<|
00000060  fd cd 25 81 c0 ff 84 50  63 f5 99 d3 dc 7c 9e 9f  |..%....Pc....|..|
00000070  a8 56 56 e9 62 d0 0c 3c  29 27 49 8b d9 b4 93 48  |.VV.b..<)'I....H|
00000080  8e c9 9a 03 02 32 d5 61  ff 6e f1 e6 a0 73 f0 af  |.....2.a.n...s..|
00000090  d0 1e 6c d0 22 34 d3 46  0d 75 7e 2a 27 42 fd 9d  |..l."4.F.u~*'B..|
000000a0  96 28 f2 c9 0d 77 ad fc  82 db 4e e4 8f c9 bf 11  |.(...w....N.....|
000000b0  0f 88 75 e9 bc 56 9e ef  1d 18 0c 18 49 cf a5 04  |..u..V......I...|
000000c0  7e 56 a0 e4 f5 51 fb 8d  44 f2 99 24 e0 bc e0 d6  |~V...Q..D..$....|
000000d0  6d 4a c7 1e 78 ec e1 bd  54 6f e9 7a 2c 5d 26 ef  |mJ..x...To.z,]&.|
000000e0  2c c3 2b 56 b8 6a 69 1c  4a 62 f5 58 6b ef 12 92  |,.+V.ji.Jb.Xk...|
000000f0  47 08 fc 61 a1 01 00 8d  98 92 e0 72 52 75 73 a8  |G..a.......rRus.|
00000100  cd 8d df 22 0a db 24 4a  e8 6c f1 33 0b 60 4b 94  |..."..$J.l.3.`K.|
00000110  4b e8 c2 3c 39 45 9e d2  48 39 ba dd 01 b6 6d 93  |K..<9E..H9....m.|
00000120  22 d4 04 fa 2f ba ac 84  ce f4 63 af 31 28 b5 f0  |".../.....c.1(..|
00000130  0c a1 ab 9f 86 6d dd 3c  1f 4a f8 0a              |.....m.<.J..|
0000013c
[root@master ~]# ETCDCTL_API=3 etcdctl   --endpoints=https://127.0.0.1:2379   --cacert=/etc/ssl/etcd/ssl/ca.pem   --cert=/etc/ssl/etcd/ssl/admin-master.pem   --key=/etc/ssl/etcd/ssl/admin-master-key.pem   get /registry/secrets/default/my-secret4 | hexdump -C
00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 6d 79 2d 73 65 63  |s/default/my-sec|
00000020  72 65 74 34 0a 6b 38 73  3a 65 6e 63 3a 61 65 73  |ret4.k8s:enc:aes|
00000030  63 62 63 3a 76 31 3a 6b  65 79 31 3a f4 d4 08 f8  |cbc:v1:key1:....|
00000040  76 dd e0 ce 4a c7 81 47  4e 21 44 7f 80 5b bc 6c  |v...J..GN!D..[.l|
00000050  ec 1c a6 2a dc 05 e3 64  bb 8d dd c9 7c de ed 08  |...*...d....|...|
00000060  e7 88 9c 9d 28 c3 e8 1d  b4 f4 bd 04 d8 b2 04 c0  |....(...........|
00000070  fd ac 7e 4b af d0 31 ef  7b 79 37 85 a9 15 99 68  |..~K..1.{y7....h|
00000080  30 d4 52 54 39 1d 93 94  b7 c5 ac 45 c9 ff 39 1b  |0.RT9......E..9.|
00000090  c9 c6 dc 08 5c 67 42 eb  07 8b 8a 78 dd 5f 74 05  |....\gB....x._t.|
000000a0  2f 1f 05 35 cc d0 68 5f  4b 1a 82 2f a7 03 bd a3  |/..5..h_K../....|
000000b0  83 26 70 5b 21 25 55 5f  48 ad 17 c9 bb b2 25 cf  |.&p[!%U_H.....%.|
000000c0  4b 76 3b 8e 01 5d 2f 21  c9 55 0b fd f7 49 3e 15  |Kv;..]/!.U...I>.|
000000d0  bb e2 02 78 4f 6b ea 3d  e1 f6 46 a6 31 64 bf d9  |...xOk.=..F.1d..|
000000e0  95 6d b7 38 03 22 26 43  7b 0d ce 53 6b 3f a0 c7  |.m.8."&C{..Sk?..|
000000f0  b7 f8 04 e9 53 74 f9 88  cd 16 30 bd 7e ac 5a 8d  |....St....0.~.Z.|
00000100  e9 a3 ef e9 f6 b3 43 01  66 d5 9c 28 4c d4 b8 93  |......C.f..(L...|
00000110  62 fd 7f 13 84 9e 07 68  84 fb ef c6 81 1e e4 a4  |b......h........|
00000120  64 5e da 07 13 72 6b 01  5c 4c 20 e5 36 51 5e 60  |d^...rk.\L .6Q^`|
00000130  9c 5c 52 9e fb b6 7c c4  12 81 d5 89 0a           |.\R...|......|
0000013d