interplanetary detour

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

Master Node와 Worker Node 생성 및 기본 설정

1. k8s-m 설치(ubuntu-20.04.2-live-server-amd64.iso)

2. k8s-m IP 주소 설정(netplan apply & shutdown) 및 스냅샷

3. k8s-m 클론떠서 k8s-w1, k8s-w2, k8s-w3 생성

4. 워커 노드 하나씩 접속하여 IP 주소 설정(netplan apply & shutdown) 및 스냅샷

* Master는 메모리 4GB, CPU 2개로 잡고 Worker는 메모리 2GB, CPU 1개로 잡는다.

kubeadm 으로 k8s 클러스터 생성 & CNI 설치

# 마스터 노드에서 클러스터 초기화 (K8s version v1.21.1)
kubeadm init --apiserver-advertise-address 192.168.79.200 --pod-network-cidr=172.16.0.0/16 --service-cidr 10.10.0.0/16

# 출력 내용 중 아래 2줄을 워커 노드에서 입력
kubeadm join 192.168.79.200:6443 --token t9fzfv.dxvtsz75l418ojf1 \
--discovery-token-ca-cert-hash sha256:055a3aef6fb8e930bff50da508007748fe97d3683c312c91c877069129930642

# k8s 관리를 위한 사용자(현재 root 사용자) 설정
echo $HOME
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config

# CNI - calico install : Pod 대역 자동으로 인식 (명령어 한 줄씩)
curl -O https://docs.projectcalico.org/manifests/calico.yaml
sed -i 's/policy\/v1beta1/policy\/v1/g' calico.yaml
kubectl apply -f calico.yaml

# calicoctl install

curl -o kubectl-calico -O -L "https://github.com/projectcalico/calicoctl/releases/download/v3.19.1/calicoctl"

chmod +x kubectl-calico

mv kubectl-calico /usr/bin

# Source the completion script in your ~/.bashrc file
echo 'source <(kubectl completion bash)' >>~/.bashrc
echo 'source <(kubeadm completion bash)' >>~/.bashrc

# alias kubectl to k
echo 'alias k=kubectl' >> ~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc

* 본인 VMnet8(NAT)의 IP 대역대에 맞게 수정하여 적용

* 출력되는 해시값이 다 다르기 때문에 본인 커맨드 창에 뜬 명령어를 긁어야 함

노드 상태 확인 명령어들

watch -d -n 2 "kubectl get node"

kubectl get node
kubectl get node -w

kubectl-calico node status

kubectl describe node k8s-w1

kubectl get nodes -o wide

조금 시간이 지난 후 wide 명령어를 쳐서 STATUS가 전부 Ready 상태로 올라와 있으면 설정 성공.

이 4개의 서버는 calico라는 네트워크를 통해 하나의 클러스터로 묶여 있는 상태이다.

kubectl Commands Cheat Sheet

https://kubernetes.io/ko/docs/reference/kubectl/cheatsheet/