interplanetary detour

WAF (Well Architected Framework)

Web Application Firewall과 헷갈리지 말자.
설계를 검토해주는 역할을 한다.
보안, 안전성, 비용 최적화, 성능 효율성, 운영 우수성 5가지 항목을 확인.

대규모 아키텍처 다이어그램

S3 vs. EBS

S3 (Simple Storage Service)

Region Level로 만들 수 있는 Web 기반의 스토리지 서비스.
위 다이어그램에 있는 양동이 모양의 '정적 자산'이 바로 이 S3이다.
S3 안에 여러 개의 Bucket이 있고, Bucket 안에 Object 단위로 파일을 저장한다.

업로드한 파일의 일부만 변경되어도 전체 파일을 처음부터 다시 업로드해야 하므로 S3에는 정적인 파일을 저장하는 편이 좋다(WORM : Write Once Read Many).
주로 온프레미스, AMI, EBS의 백업 데이터를 저장하며, Data Lake로써 머신 러닝 등에 사용될 수도 있다.
병렬(Load Balancing)로 읽기/쓰기가 가능하다.

1. 파일 1개 당 5TB 이하
2. 업로드 파일 갯수 무제한
3. 스토리지 전체 사이즈 무제한
4. 업로드 횟수 무제한
이라는 특징을 가지고 있다. 업로드 관련 기능은 무료이지만 스토리지로부터 데이터를 GET할 때 비용이 발생한다.

S3 Bucket Policy
Permissions의 Bucket Policy에 JSON 형식으로 Bucket 별 액세스 제어 정책을 정의할 수 있다.
디폴트로는 비공개이며, 외부로부터의 모든 접근 허용 또는 일부 접근 허용 등의 설정이 가능하다.

Amazon S3 Transfer Acceleration
파일의 근원지로부터 S3에 업로드 되기까지 100% 인터넷 회선을 통하는 대신 이동 과정 중간부터는 Amazon CloudFront(One of Edge Location Features)를 이용해 Amazon Backbone Network를 통한 보다 안전하고 신속한 데이터 이동이 가능하다.

AWS Physical Data Transfer Solutions
10TB 초과의 대용량 데이터를 더 빨리 전송할 수 있는 물리적 솔루션이다.
AWS Snowball은 기내용 캐리어 정도 크기의 저장소이다. 약 80TB의 데이터를 물리적으로 운송할 수 있다.
AWS Snowmobile은 대형 트럭 크기의 데이터 트럭이다. 약 100PB의 데이터를 물리적으로 운송할 수 있다.

S3 4 Tiers
S3 Standard
S3 Standard IA (Infrequent Access)
S3 One Zone IA
S3 Glacier (Backup)

아래로 갈 수록 저장 비용↓ 검색 비용 및 속도↓
Glacier는 신속 검색 5분, 표준 검색 3~5시간, 대량 검색 5~12시간이 소요된다.
S3 Intelligent Tiering : AWS에서 자동으로 데이터들을 티어링한다.

ILM (Information Lifecycle Management)

Amazon S3 수명 주기 정책을 사용하면 생성 후 기간을 기준으로 객체를 삭제 또는 이동할 수 있다.

EBS (Elastic Block Store)

하나의 인스턴스에 Attach 되어 종속되어지는 스토리지이다. EBS 1개 당 최대 16TB까지 저장 가능하다.
외장 하드를 구매할 때와 같이 리소스를 Provisioning할 때 그만큼 지불한다.

인스턴스의 데이터 저장용으로 실제 물리적 호스트의 Local Storage 이용 시 인스턴스가 멈췄다가 다시 시작될 경우 다른 물리적 호스트에서 실행될 것이기 때문에(같은 AZ 내일 뿐) 휘발성인 Local Storage가 아닌 별도의 Storage Farm에 있는 EBS를 인스턴스에 매핑시켜 데이터를 저장하게 한다(네트워크를 통한 연결).

Database on AWS

DB 결정 시 고려할 사항으로는 확장성, 총 스토리지 요구 사항, 객체 크기 및 유형, 내구성이 있다.

DB - RDS (Relational Database Service)

AWS에서 관계형 데이터베이스는 Oracle DB, MS-SQL Server, MySQL, MariaDB, PostgreSQL, Aurora 총 6가지를 사용할 수 있다. 이 중 Aurora는 AWS에서 자체 개발한 DB로 완전관리형 데이터베이스이며, MySQL, PostgreSQL과 호환이 가능하다. Aurora를 플랫폼으로 MySQL 사용 시 기존의 최대 5배 처리량, PostgreSQL의 경우 최대 3배.
수직적으로 리소스 조절(Scale Up/Down).

RDS Security
I/O 경합을 막기 위해 Read Replica를 만들어 읽기 부하를 분산시킬 수 있다.
Amazon Aurora는 15개, 나머지 5가지 RDB는 5개까지 Read Replica를 만들 수 있다.
저장 시 KMS를 이용해서 암호화. 통신 시 SSL 암호화 사용.

DB - NoSQL

Document DB : MongoDB
GraphDB : Amazon Neptune, Cassandra
Key-Value DB : Amazon DynamoDB, Redis

DynamoDB는 완전관리형 비관계형 데이터베이스 서비스이다.
Amazon의 전자상거래 서비스에서 일어나는 많은 트랜잭션을 처리하기 위해 개발되었다.
이벤트 중심 프로그래밍(서버리스 컴퓨팅)이다.
수평적으로 리소스 조절(Scale In/Out).

Eventually Consistance Read(DynamoDB default) : 레이턴시 최소화. 게임 등에서 사용한다.
Strongly Consistance Read : 금융권 등에서 사용. 계좌의 잔고가 동기화되지 않으면 큰일이므로 강력하게 읽기 일관성을 정의한다.

DynamoDB Security
Row, Column 등 모든 것에 대해 액세스 권한 부여 가능.
저장 시 KMS를 이용해서 암호화. 통신 시 SSL 암호화 사용.

AWS DMS (Database Migration Service)

AWS는 대부분의 상용 및 오픈 소스 데이터베이스와의 마이그레이션을 지원.
데이터베이스가 너무 클 경우 AWS Snowball Edge(Snowball + Computing Resource)와 연동해 마이그레이션 할 수 있다.

AWS Schema Conversion Tool
이종 마이그레이션의 경우 AWS SCT를 통해 데이터베이스 엔진을 변환해 마이그레이션이 가능하다.

Cattles & Puppets

클라우드에선 트래픽이 급증하는 시기에 필요한 만큼 즉각적으로 인스턴스를 늘리고, 평상시엔 적은 인스턴스로 유지하며 On-demand(종량제)로 리소스를 관리할 수 있다. 반려동물처럼 애지중지하며 관리할 필요없이 가축처럼 다룬다.

AWS Global Infrastructure

Server → Data Center(1~6) → Availability Zone(2~) → Region

1. 수만 개의 서버가 하나의 데이터센터 안에 존재함.

2. 데이터센터 1~6개를 논리적으로 하나의 AZ로 묶음.

3. AZ 최소 2개 이상(Multi-AZ Mirroring for HA)을 하나의 Region으로 묶음.

한 Region의 AZ들은 기본적으로 서로 격리되어 있지만, 한 Region의 AZ들은 지연 시간이 짧은 링크를 통해 연결되어 있어 미러링 되어지고 있음.

또한 각 Region 간 연결이 가능한데, 일본같은 경우 지진 발생으로 도쿄 Region과 오사카 Region이 동시에 Failure될 수 있으므로 타국의 Region과 AWS Backbone Network를 통해 링크를 연결한다.

*2021.11.09 기준 전 세계 Region 25개, AZ 81개

PoP(Points of Presence)

Edge Location : 176개

Edge Cache : 11개

캐시 기능을 하며, 리전 주변에 있음.

PoP 주요 기능

Amazon Route 53 : DNS

Amazon CloudFront : CDN(Content Delivery Network) = Caching

AWS WAF(Web Application Firewall) : L7 Security

AWS Shield : DDoS 공격 완화

VPC (Virtual Private Cloud)

VPC는 퍼블릭 클라우드 환경에서 외부에 노출되면 안 되는 데이터를 인터넷으로부터 보호하기 위한 공간이다.

인터넷이라는 바다에서 가두리 양식을 쳐 놓은 것과 같다.

Soft Limit으로 하나의 계정 당 최대 VPC 5개까지 생성 가능하고, Hard Limit(AWS에 요청)으로는 최대 100개까지 생성 가능하다.

VPC로 인프라를 구성하는 기본 패턴은 다중 VPC와 복수 계정 두 가지이다.

다중 VPC는 하나의 계정에서 VPC를 여럿(주로 부서별로) 생성해 사용하는 것이고, 복수 계정은 계정 자체를 여러 개 만들어 계정 당 VPC 하나로 운용하는 것이다. 과금되는 주체가 'AWS 계정'이기 때문에 주로 다중 VPC 방식을 사용한다.

prefix 24 기준 IP를 251개밖에 못 쓰는 이유

10.0.0.1 : IGW

10.0.0.2 : DNS

10.0.0.3 : AWS 시스템에서 예비로 지정

10.0.0.255 : 브로드캐스트 주소

Public/Private Subnet

Seoul Region 기준 4개의 AZ가 있는데, 이 중 a와 b의 리소스를 받아 각각 2개의 서브넷을 만들었다.

각 Subnet마다 설정해 준 라우팅 테이블에 따라 Public Subnet은 인터넷에 직접 접속, Private Subnet은 NAT Gateway → Internet Gateway를 순서대로 통해 인터넷에 접속한다.

EC2 & SG

Amazon EC2(Elastic Compute Cloud) 서비스를 이용해 EC2 Instance를 생성하여 애플리케이션 등을 구동할 수 있다.

Public Subent엔 Application, Private Subnet엔 DB를 올려 서비스할 때 외부에서 DB로 접근하지 못하도록 가상의 방화벽을 설정해야 한다.

VPC 설정에서 SG(Security Group)를 잡아주는데(Instance Level = 각 인스턴스마다), App Instance에선 0.0.0.0/0:80, DB Instance에선 0.0.0.0/0:3306으로 설정하면 된다(WebApp, MySQL).

서브넷 레벨로 적용하는 NACL(Network Access Control List)도 존재하는데 아래의 글을 참고 바람.

https://blog.naver.com/adaylily/220953739322

Types of EC2 Instance (Not All)

범용 : T, M

고성능 컴퓨팅 최적화(CPU) : C

메모리 최적화(RAM) : R

가속화된 컴퓨팅(GPU - ML, 3D Rendering) : P

스토리지 최적화(비용↓ IOPS↑) : H

ex) t3.large

t = 범용

3 = 3세대

large = 리소스 성능

ROI(Return on Investment)

userdata, metadata 확인 방법

http://169.254.169.254/latest/userdata

http://169.254.169.254/latest/metadata

PVLAN의 개요 및 특징

• PVLAN이란 같은 VLAN 내에서 또 한 번 논리적인 분리를 하는 것을 말한다.
• 모두를 감싸는 VLAN을 Primary VLAN이라고 부르고, 그 안에 소속된 VLAN은 Secondary VLAN이라고 부른다.
• Secondary VLAN에는 2가지 타입이 있는데, 그 중 Community는 같은 Community VLAN 안에서는 Host 간 통신이 가능한 것이고(서로 다른 Community 간 통신은 불가), Isolated는 같은 Isolated VLAN 안에서도 서로 통신이 불가한 것을 말한다. 서로 다른 Secondary VLAN 간의 통신은 아예 불가능하다고 보면 된다.
• 하나의 네트워크 안에서 VLAN ID는 절대적이다. Secondary VLAN을 만들 때에도 Primary VLAN 바깥의 VLAN과 중복되는 VLAN ID를 사용할 수 없다는 의미이다.
• Promiscuous Port는 인터넷과 연결되는 포트를 말하는데 그렇기 때문에 이 Promiscuous Port는 모든 Host로부터 접근이 가능하다. show vlan private-vlan 명령어에서도 Promiscuous Port가 모든 VLAN에 포함되어 있음을 확인할 수 있다. VLAN 멤버의 개념보다는 그냥 접근이 가능하다는 의미.

PVLAN Configuration

VTP 끄기

ASW(config)# vtp mode off

Secondary VLAN(Isolated) 생성

ASW(config)# vlan 201

ASW(config-vlan)# private-vlan isolated

Secondary VLAN(Community) 생성

ASW(config)# vlan 202

ASW(config-vlan)# private-vlan community

Primary VLAN 생성 및 Association 생성

ASW(config)# vlan 100

ASW(config-vlan)# private-vlan primary

ASW(config-vlan)# association 201,202

Promiscuous Port 설정 및 VLAN 매핑

ASW(config)# int e1/0

ASW(config-if)# switchport mode private-vlan promiscuous

ASW(config-if)# switchport private-vlan mapping 100 201,202

VLAN 202에 연결되는 인터페이스들을 host로 설정 및 VLAN 202를 VLAN 100에 포함시키기

ASW(config)# int range e0/0 - 1

ASW(config-if-range)# switchport mode private-vlan host

ASW(config-if-range)# switchport private-vlan host-association 100 202

VLAN 201에 연결되는 인터페이스들을 host로 설정 및 VLAN 201을 VLAN 100에 포함시키기

ASW(config)# int range e0/2 - 3

ASW(config-if-range)# switchport mode private-vlan host

ASW(config-if-range)# switchport private-vlan host-association 100 201

Docker Summary

리눅스 컨테이너 기반의 오픈 소스 가상화 플랫폼.

도커 컨테이너 이미지는 운영체제에 구애받지 않고, 새롭게 패키지를 설치할 필요도 없으며, 각종 라이브러리에 대한 의존성의 문제 또한 걱정할 필요가 없다. 만든 컨테이너를 다른 서버로 그대로 옮겨다 놓으면 환경, 모듈 등이 그대로 적용되기 때문에 별도의 환경설정도 필요하지 않다.

도커 컨테이너들은 HostOS로부터 GuestOS로 물리적 리소스를 1/n로 나누어 할당받는 것이 아닌 HostOS의 리소스를 다이렉트로 접근해 모든 컨테이너가 공유하며 사용하기 때문에 다른 가상화 방법에 비해 속도가 매우 빠르고 효율적이다.

도커는 Layered File System 기반이다. 마치 포토샵처럼 레이어 단위로 컨테이너 이미지를 생성하며, 이 컨테이너들은 서버 위에서 각각 하나의 프로세스처럼 작동하지만 컨테이너 자신은 스스로가 운영체제인 것처럼 생각한다.

각 도커 컨테이너는 서로 간에 절대적으로 격리(Isolated)되어 있어 한 컨테이너에 어떤 변화가 발생하더라도 다른 컨테이너에 영향을 주지 않는다.

Registry, Images, Containers, Commands and Daemon in Docker

• Public과 Private Registry 중 Public Repository를 Docker Hub라고 부르며, Docker Hub에서 이미지를 올리는 것을 Push, 이미지를 받아 오는 것을 Pull이라고 한다. Pull한 이미지는 /var/lib/docker/overlay2에 저장된다.
• Build는 직접 이미지를 생성하는 것인데 여러가지 베이스 환경을 설정해서 이미지 파일을 만든 후에 Run을 하여 프로세스에 올려 컨테이너로 만들거나 Docker Hub로 Push 할 수 있다.
• Run은 이미지를 실행하는 명령어인데 이미지가 없을 경우 Pull로 레지스트리에서 이미지를 받아온 후 Run, Start까지 한다. Run을 하게 되면 최대 3가지 처리가 동시에 이루어지고 이미지가 비로소 컨테이너가 되고 프로세스에 올라가게 된다.
• 실행되고 있는 컨테이너를 Commit해서 현 상태를 이미지로 만들어 Docker Hub로 Push 할 수 있다.
• 메모리에 올라간 컨테이너를 Kill하면 컨테이너의 프로세스가 종료된다.
• 메모리에 올라가면 컨테이너(read/write), 올라가지 않은 상태면 이미지(read only)이다.
• 이 모든 것을 백그라운드에서 실행하고 관리하는 서비스를 dockerd(Docker Daemon)이라고 한다.
• Docker Daemon을 돌리는 머신은 Docker Host라고 한다(Linux Server).

아래는 Docker Hub의 링크인데 Official Image 인증 마크가 있는 이미지는 안전하지만 그 이외의 이미지는 안전을 보장할 수 없다.

https://hub.docker.com 

레이어화 된 컨테이너 이미지

도커의 컨테이너 이미지는 3단의 레이어로 구성되며, 각 레이어는 고유의 UUID(Process ID)를 갖고 있다.

• Base Image Layer
  
  • 주로 가상적으로 OS를 구성하는 레이어.
  • 컨테이너의 가장 밑단, 배경이 되는 환경이 구축된다. 컨테이너의 냉동 설비라고 볼 수 있다.
• Source Code Layer
  
  • 실행할 소스 코드가 위치하는 레이어.
  • 컨테이너에 싣는 도구라고 볼 수 있다.
• Execution Layer
  • 실제로 소스 코드를 실행하는 레이어.
  • 컨테이너의 도구를 사용하게 되는 레이어이다.

가상환경 플랫폼 실행 단위

가상머신: Instance

도커: Container

쿠버네티스: Pod

Containers in Pod

기본적으로 하나의 Pod 당 1개의 컨테이너를 갖게 하는 걸 권장한다. 사이드카로 보조 컨테이너를 넣어 2개의 컨테이너를 돌아가게 하는 경우도 있지만, 3개부터는 권장하지 않는다.

쿠버네티스에서는 NAT 통신 없이도 Pod 고유의 IP + 컨테이너 별 Port 주소를 통해 각 컨테이너에 접근할 수 있다. 같은 Pod 내의 컨테이너들은 사실 상 모두 같은 IP 주소를 가진 상태이기에 서로 localhost와 개별 포트넘버를 통해 네트워크 접근을 한다.

같은 Pod 내의 컨테이너들은 반드시 동일 노드에 할당되며 동일한 생명 주기를 가진다. Pod 삭제 시, 그 Pod 내의 모든 컨테이너가 전부 같이 삭제된다. 또한 모두 같은 볼륨에 연결되어 있어 파일 시스템을 기반으로 서로 파일을 주고 받을 수 있다.

[labels] in [metadata]

# 원래 상태

kubectl get pod mynginx -o yaml

# 라벨 추가

kubectl label pod mynginx hello=world

# 변경점 확인

kubectl get pod mynginx -o yaml

# 라벨 확인

kubectl get pod mynginx --show-labels

# run label이 다른 또 하나의 Pod 생성

kubectl run yournginx --image nginx

# key가 run인 Pod 출력

kubectl get pod mynginx -l run

-l = label

# key가 run, value가 mynginx인 Pod 출력

kubectl get pod mynginx -l run=mynginx

# 워커 노드1에 라벨 부여

kubectl label node k8s-w1 disktype=ssd

# 워커 노드2에 라벨 부여

kubectl label node k8s-w2 disktype=hdd

# 워커 노드3에 라벨 부여

kubectl label node k8s-w3 disktype=hdd

# disktype에 대해 노드들의 라벨 확인

kubectl get node --show-labels | grep disktype

# 새로 만들 Pod(node-selector)의 yaml 파일 생성

nano node-selector.yaml

# node-selector.yaml
apiVersion: v1
kind: Pod
metadata:
  name: node-selector
spec:
  containers: 
  - name: nginx
    image: nginx
  # 특정 노드 라벨 선택
  nodeSelector:
    disktype: ssd

# nodeSelector 프로퍼티로 인해 이 Pod는 disktype이 ssd인 노드에서 실행될 것이다.

# node-selector Pod 생성

kubectl apply -f node-selector.yaml

# Pod가 어느 노드에서 실행되고 있는지 확인 : disktype을 ssd로 지정해뒀던 k8s-w1에서 실행되고 있을 것이다.

kubectl get pod node-selector -o wide

# node-selector.yaml 수정

nano node-selector.yaml

# node-selector.yaml
apiVersion: v1
kind: Pod
metadata:
  name: node-selector
spec:
  containers: 
  - name: nginx
    image: nginx
  # 특정 노드 라벨 선택
  nodeSelector:
    disktype: hdd

# disktype이 hdd인 노드는 2개이기 때문에 쿠버네티스 마스터가 알아서 판단해서 할당한다.

# yaml 파일 재적용

kubectl apply -f node-selector.yaml

# Pod가 어느 노드에서 실행되고 있는지 확인 : k8s-w2, k8s-w3 중 하나일 것이다.

kubectl get pod node-selector -o wide

[command], [args] in [spec]

# vi editor 사용해보기 - i로 편집 모드 진입 → 수정 후 esc키 → :wq 입력으로 저장 & 나가기

vi cmd.yaml

# cmd.yaml
apiVersion: v1
kind: Pod
metadata:
  name: cmd
spec:
  restartPolicy: OnFailure
  containers: 
  - name: nginx
    image: nginx
    # 실행명령
    command: ["/bin/echo"]
    # 파라미터
    args: ["hello"]

# 여기서 눈여겨 봐야 하는 부분은 restartPolicy인데, Always, Never, OnFailure 3가지 값을 줄 수 있다.

# Always: Pod 종료 시 항상 재시작(default), Never: 재시작을 시도하지 않음, OnFailure: 실패 시 재시작

# 그런데 여기서 echo 명령은 웹 서버와 다르게 실행 후 종료되기 때문에 OnFailure로 주어야 하는 것.

# Pod 생성

kubectl apply -f cmd.yaml

-f = file

# 로그 확인 : 만약 restartPolicy를 Always로 했다면 무수히 많은 hello가 찍힐 것이다.

kubectl logs -f cmd

-f = flow

Volume Mounting

# volume.yaml 파일 생성

vi volume.yaml

# volume.yaml
apiVersion: v1
kind: Pod
metadata:
  name: volume
spec:
  containers: 
  - name: nginx
    image: nginx

    # 컨테이너 내부의 연결 위치 지정
    volumeMounts:
    - mountPath: /container-volume
      name: my-volume
  
  # host 서버의 연결 위치 지정
  volumes:
  - name: my-volume
    hostPath:
      path: /home

# [spec]-[containers]-[volumeMounts] 부분에 컨테이너 내부의 경로와 이름을 잡고,

# [spec]-[volumes] 부분에 노드(호스트 서버) 쪽의 경로와 이름을 잡는다.

# Pod 생성

kubectl apply -f volume.yaml

# volume Pod 안으로 접속해 연결시켜준 위치를 ls 명령어를 통해 확인한다.

kubectl exec volume -- ls /container-volume

# 호스트 서버의 디렉토리에서 목록 출력

ls /home

[resources]-[limits]-[cpu], [memory] in [spec] for Resource Management

# limits.yaml 파일 생성

vi limits.yaml

# limits.yaml
apiVersion: v1
kind: Pod
metadata:
  name: limits
spec:
  restartPolicy: OnFailure
  containers: 
  - name: mynginx
    image: python:3.7
    command: [ "python" ]
    args: [ "-c", "arr = []\nwhile True: arr.append(range(1000))" ]
    resources:
      limits:
        cpu: "500m"
        memory: "1Gi"

# 파이썬 이미지를 사용해 파이썬 코드를 작성하고 수행하는 컨테이너를 만들 수 있다.

# limits Pod 생성

kubectl apply -f limits.yaml

# watch 명령어의 지속적인 체크로 STATUS 변화 확인 : Running → OOMKilled

watch -d 'kubectl get pod limits'

[livenessProbe] in [spec] for Health Check

# yaml 파일 생성

vi liveness.yaml

# liveness.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness
spec:
  containers: 
  - name: nginx
    image: nginx
    livenessProbe:
      httpGet:
        path: /live
        port: 80

# 상태 확인 및 자가치유 부분은 확인 과정이 복잡하기 때문에 단순히 위의 속성을 주게 되면

#정상적으로 작동하는지 실시간으로 체크하고 자가치유를 수행한다는 것만 알면 될 것 같다.

2개의 컨테이너 실행 (Sidecar)

# yaml 파일 생성

vi second.yaml

# second.yaml
apiVersion: v1
kind: Pod
metadata:
  name: second
spec:
  containers: 
  - name: nginx
    image: nginx
  - name: curl
    image: curlimages/curl
    command: ["/bin/sh"]
    args: ["-c", "while true; do sleep 5; curl -s localhost; done"]

# containers 아래에 name이 두 개가 있는 모습. 하나의 Pod 안에 두 개의 Container를 생성하는 것이다.

# 아래의 명령어는 5초마다 로컬호스트로 시그널을 보내며, 응답을 받지 못하면 에러가 뜨게 되는 코드이다.

# Pod 생성

kubectl apply -f second.yaml

# 생성 확인. 그리고 다른 Pod들과는 다르게 second는 READY 컬럼에 2개가 있는 것을 볼 수 있다.

kubectl get pod

# second 컨테이너의 (nginx 컨테이너에 대한) 로그를 출력

kubectl logs second -f -c nginx

-f = flow

-c = container

# Pods 확인 명령어

kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\sort

Init Container

# yaml 파일 생성

vi init-container.yaml

# init-container.yaml
apiVersion: v1
kind: Pod
metadata:
  name: init-container
spec:
  restartPolicy: OnFailure
  containers: 
  - name: busybox
    image: k8s.gcr.io/busybox
    command: [ "ls" ]
    args: [ "/tmp/moby" ]
    volumeMounts:
    - name: workdir
      mountPath: /tmp
  initContainers:
  - name: git
    image: alpine/git
    command: ["sh"]
    args:
    - "-c"
    - "git clone https://github.com/moby/moby.git /tmp/moby"
    volumeMounts:
    - name: workdir
      mountPath: "/tmp"
  volumes:
  - name: workdir
    emptyDir: {}

# 메인 컨테이너가 실행되기 전에 초기화 컨테이너에서 미리 git pull을 받아서

# 컨테이너끼리의 공유 공간인 emptyDir volume(/tmp)를 통해 git 레파지토리를 전달한다.

# Pod 생성

kubectl apply -f init-container.yaml

# initContainer 로그 확인

kubectl logs init-container -f -c git

# 메인 컨테이너(busybox) 로그 확인

kubectl logs init-container

Delete all Pods

kubectl delete pod --all

아래 사진은 쿠버네티스의 전체적인 프로세스 구조이다.

Control Plane Components

API Server

API 서버는 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트이다. API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드이다.

쿠버네티스 API 서버의 주요 구현은 kube-apiserver 이다. kube-apiserver는 수평으로 확장되도록 디자인되었다. 즉, 더 많은 인스턴스를 배포해서 확장할 수 있다. 여러 kube-apiserver 인스턴스를 실행하고, 인스턴스간의 트래픽을 균형있게 조절할 수 있다.

etcd

모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소.

쿠버네티스 클러스터에서 etcd를 뒷단의 저장소로 사용한다면, 이 데이터를 백업하는 계획은 필수이다.

etcd에 대한 자세한 정보는, 공식 문서를 참고한다.

Scheduler

노드가 배정되지 않은 새로 생성된 파드 를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트.

스케줄링 결정을 위해서 고려되는 요소는 리소스에 대한 개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약, 어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인을 포함한다

Controller Manager

컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트.

논리적으로, 각 컨트롤러는 분리된 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다.

이들 컨트롤러는 다음을 포함한다.

• 노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
• 레플리케이션 컨트롤러: 시스템의 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞은 수의 파드들을 유지시켜 주는 책임을 가진다.
• 엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채운다(즉, 서비스와 파드를 연결시킨다.)
• 서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.

Node Components

kubelet

클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.

Kubelet은 다양한 메커니즘을 통해 제공된 파드 스펙(PodSpec)의 집합을 받아서 컨테이너가 해당 파드 스펙에 따라 건강하게 동작하는 것을 확실히 한다. Kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않는다.

kube-proxy

kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 서비스 개념의 구현부이다.

kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.

kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.

Cloud controller manager

클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트이다. 클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 해 준다.

cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행한다. 자신의 사내 또는 PC 내부의 학습 환경에서 쿠버네티스를 실행 중인 경우 클러스터에는 클라우드 컨트롤러 매니저가 없다.

kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적으로 독립적인 여러 컨트롤 루프를 단일 프로세스로 실행하는 단일 바이너리로 결합한다. 수평으로 확장(두 개 이상의 복제 실행)해서 성능을 향상시키거나 장애를 견딜 수 있다.

다음 컨트롤러들은 클라우드 제공 사업자의 의존성을 가질 수 있다.

• 노드 컨트롤러: 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공 사업자에게 확인하는 것
• 라우트 컨트롤러: 기본 클라우드 인프라에 경로를 구성하는 것
• 서비스 컨트롤러: 클라우드 제공 사업자 로드밸런서를 생성, 업데이트 그리고 삭제하는 것

자료 출처: https://kubernetes.io/ko/docs/concepts/overview/components/

Operation

자료 출처: Pod | 쿠버네티스 안내서 (subicura.com)

yaml 파일을 통한 Pod 생성/수정

# yaml 파일 생성
nano mynginx.yaml

# yaml 파일 작성

apiVersion: v1
kind: Pod
metadata:
    name: mynginx
spec:
    containers:
    - name: mynginx
      image: nginx

# yaml 파일 적용
kubectl apply -f mynginx.yaml

-f = file

# Pod 생성 확인 (뒤에 -n 등 속성을 안 붙이면 default 네임 스페이스로 잡는다)
kubectl get pod

# yaml 파일 확인
kubectl get pod mynginx -o yaml

-o = output

# 웹에서 불러온 yaml 파일로 Pod 생성
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/simple-pod.yaml

# Pod 생성 확인
kubectl get pod

# yaml 파일 확인
kubectl get pod nginx -o yaml

# yaml 파일 수정

nano mynginx.yaml

apiVersion: v1
kind: Pod
metadata:
    labels:
       hello: world
    name: mynginx
spec:
    containers:
    - name: mynginx
      image: nginx:1.17.2

# yaml 파일 재적용 (Configured 출력 확인)
kubectl apply -f mynginx.yaml

# yaml 파일 확인
kubectl get pod mynginx -o yaml

# yaml 파일 재적용 시도 (Unchanged 출력 확인)
kubectl apply -f mynginx.yaml

네임 스페이스의 명령어 속성으로써의 활용

# default 네임 스페이스

kubectl get pod -n default

-n = namespace

# 쿠버네티스가 동작하는 데에 반드시 필요한 것이 들어있는 네임 스페이스

kubectl get pod -n kube-system

# kube-system 네임 스페이스 위에서 mynginx-ns Pod 돌리기

kubectl run mynginx-ns --image nginx -n kube-system

# Pod 확인

kubectl get pod mynginx-ns -n kube-system

# 다시 지워서 원 상태로 만들기

kubectl delete pod mynginx-ns -n kube-system

kubectl Commands

https://subicura.com/k8s/guide/kubectl.html