저녁 하늘의 종이 비행기

Dart 기본 개념 정리 ( 노마드 코더 Dart 시작하기 강의 정리)

박한결 — Sun, 18 Feb 2024 13:24:54 +0900

참고

노마드 코드의 무료 강의 Dart 시작하기를 들으면서 정리한 요약본입니다.
링크에서 강의를 들을 수 있으며, 저작권 상 문제가 있다면 댓글로 알려주시면 조치하겠습니다.

Dart

Why Dart?

UI 에 최적화된 언어
빠름
두가지 컴파일러
- Dart Native ( 여러 cpu 의 아키텍처에 맞게 변환 = iOs, Android, Windows, Linux, Mac … )
  - 거의 모든 곳에서 동작하도록 컴파일 가능
  - just in time(JIT, 코드의 결과를 바로 화면으로 볼 수 있음. 가상 머신에서 동작하는 거여서 조금 느릴 수 있음. ) > 개발 도중에만 쓰임
    - 빠른 피드백이 가능함
  - ahead of time (AOT, 컴파일 먼저 > 그 결과인 바이너리 배포 ) > 배포할 때 쓰임
    - 하지만 최종 결과물은 컴파일이 되서 빠름
- Dart Web ( dart > javascript)
null safety
- 대부분의 프로그래밍 언어에서 null 참조하면 crash 나지만… dart 에서는 걱정하지 않아도 됨

How To Learn?

link: dartpad.dev

Variables

Var keyword

void main() {
  var hello = '안녕';
  // name = 1; - 업데이트 할 때에는 기존 type 과 일치해야 함
  String world = '세상';
}

관습적으로 함수나 메소드 내부에 로컬 변수를 선언할 때에는 var 사용
class에 변수 또는 property 의 경우 타입 지정
어떤 경우든 변수는 업데이트 가능함

dynamic type

var name; // dynamic type
name = 'nini';
name = 17;
name = true;

dynamic name;
if (name is String) { // name is string }
if (name is int) { // name is int }
// name is dynamic

여러가지 타입을 가질 수 있는 변수에 쓰는 키워드
사용하는게 권장되지는 않지만 유용함
따라서 꼭 필요할 때만 써야함
dynamic 변수로 작업하고 있다면 타입을 먼저 확인해야 함

nullable variables

개발자가 null 값을 참조할 수 없도록 함
- null 을 참고하면 런타임 에러가 발생하게 됨

// without null safety
bool isEmpty(String string) => string.length == 0;
main() { isEmpty(null); } // 사용자 기기에서 에러 발생 = 컴파일러가 잡지 못함

어떤 데이터 또는 변수가 null 이 될 수 있는지 명시하는 것이 nullable variable
기본적으로는 모든 변수가 non-null

String nico = 'nico';
nico = null; // not possible 

String? nico = 'nico';
nico = null; // possible
if (nico != null) { // nullable variable 일 경우 null 이 아닌지 확인해야 함 }
nico?.isNotEmpty; // 단축문법도 사용 가능

final variables

// 나중에 수정 가능한 변수가 만들어짐 
var name;
String name; 

// 추후 수정할 수 없게 만드려면 ( js, ts 의 const ) 
final name = 'x';
final String name = 'y'; // type 지정도 가능

late variables

late final x;
// do something, go to api

print(x); // 할당 전에는 접근 불가 에러 발생 

x = 'x';

print(x); // 할당 되어 접근 가능

late var y;

초기 데이터 없이 변수를 만들 수 있게 해줌

또한 final 에 쓰는 경우 최초 한번만 할당 할 수 있음

data fetching 을 할 때 유용함

constant variables

const api = 1233333; // (o) 바뀌지 않고 컴파일 될 때 이 값을 알 고 있어야 함.

const api = fetchApi(); // (x) compile time constant 가 아님. api 에서 가져와야 하는 거여서 const 가 아닌 final 이 맞음. 앱스토어에 앱을 올리기 전에 알고 있는 값이어야 함.

const max_allowed_price = 120; // compile time 에 평가되게 됨. = 앱에 담긴 코드를 앱스토어로 보내기 전에 평가 됨

js/ts 의 const 의 다름 ( 이건 오히려 final 과 비슷함 )
dart 의 const 는 compile time constant 를 만들어줌
final 과 똑같이 수정이 안됨. 즉 상수임.
하지만 더 중요한건 compile-time 에는 알고 있는 값이어야 함.

Data Types

basic data types

// 타입도 Object로 이루어져 있음
String a;
bool b;
int c;
double d;
num e; // integer or double. parent of integer and double.

lists

var numbers = [];
List numbers = [1, 2,];

// supports collection if/for

var giveMeFive = ture;
var numbers = [
    if (giveMeFive) 5, // collection if

]

string interpolation

var name = 'yeye';
// variable already exists $aa
// not exists like operation ${bb + 32}

var age = 10;
var greeting = "hello, my name is $name, and I'm ${age +3}";

use quote or double quote
use variable after $

collection for

var oldFriends = ['a', 'b'];
var newFriends = [
    'c',
    'd',
    for (var friend in oldFriends) "love $friend"
]

maps

var player = { // Map<string, object=""> player
    'name': 'me",
    'level': 99,
    'power': true,
}

Map<int, bool=""> player = {};
Map<list, bool> player = {};

Dart 에서는 모든 것이 Object ( Typescript 의 any 라고 보면 됨 )

sets

elements in the set are unique
dart set - js set, python set
dart list - js array, python list

Functions

defining a function

void say(String name){
    print("Hello $name nice to meet you!");
}

String say(String name){
    return "Hello $name nice to meet you!";
}

// arrow syntax
String say(String name) => "Hello $name nice to meet you!";

named parameters

// null safety - use default value or required
String say({String name = '', int age = 99, required String country}){ 
    return "Hello $name, your age is $age, and you come from $country";
}

say(name:'name', age:19, country:'south korea');

positional parameter vs named parameter

optional positional parameters

String say(String name, int age, [String? country = 'south korea']) => 'Hello $name, you are $age, and from $country';

say('yeye', 12);

[type? variableName = defaultValue]

QQ(Question Question) operator

?? : left ?? right > left 가 null 이면 return right
??=

String captalize(String? name) => name?.toUpperCase() ?? 'null';
capitalize(null);

String? name;
name ??= 'nico';

typedef

List reverseListOfNumbers(List list) {
    var reversed = list.reversed; // iterable
    return reversed.toList();
}

// =>

typedef ListOfIntegers = List;
ListOfIntegers reverseListOfNumbers(ListOfIntegers list) {
    var reversed = list.reversed; // iterable
    return reversed.toList();
}

alias of something tiny

Classes

first dart class

class Player {
  String name = 'hehe';
  int xp = 1500;

  void say() {
    print('hi i am $name'); // variable 이름이 중복되지 않는 이상 this 를 쓸 필요 없음.
  }
}

void main() {
  var player = Player(); // new Player () not required
  print(player.name);
  print(player.name);
  player.say();
}

constructors

class Player {
    // version 1 
  late String name;
  late int xp;

  Player(String name, int xp) {
    this.name = name;
    this.xp = xp;
  }

    // version 2 : 깔끔하고 중복 코드가 없음 
    String name;
  int xp;
  Player(this.name, this.xp);

  void say() {
    print('hi i am $name'); // variable 이름이 중복되지 않는 이상 this 를 쓸 필요 없음.
  }
}

void main() {
  var player = Player('hehe', 999); // new Player () not required
  print(player.name);
  player.say();
}

named constructor parameters

class Player {
  String name;
  int xp;
  String team;
  int age;

  Player(
      {required this.name, required this.xp, required this.team, this.age = 3});

  void say() {
    print('hi i am $name');
  }
}

void main() {
  var player = Player(name: 'hehe', xp: 999, team: 'blue', age: 1);
  print(player.name);
  player.say();
}

named constructors

class Player {
  String name, team;
  int xp, age;

  // constructor ( 생성자 )
  Player(
      {required this.name,
      required this.xp,
      required this.team,
      required this.age});

  // named constructor
  Player.test1(
      {required this.name,
      required this.xp,
      this.team = 'hello',
      this.age = 4});

  // use : initiallize Player here
  Player.test2({required name})
      : this.name = name,
        this.xp = 3,
        this.team = 'team',
        this.age = 5;

  void say() {
    print('hi i am $name');
  }
}

void main() {
  var player = Player(
    name: 'hehe',
    xp: 999,
    team: 'blue',
    age: 1,
  );
  print(player.name);

  var newPlayer = Player.test1(name: 'name', xp: 5);
  print(newPlayer.name);
}

cascade notation

void main() {
  var player = Player(
    name: 'hehe',
    xp: 999,
    team: 'blue',
    age: 1,
  )
    ..name = 'las'
    ..xp = 1
    ..team = 'aa'
    ..age = 3;
}

enums

enum Team { read, blue }
//
Team team;

// ...
..team = Team.blue;

abstract classes

// 일종의 청사진
abstract class Human {
  void walk();
}

class Player extends Human {
  @override
  void walk() {
    // TODO: implement walk
  }
}

void main() {}

inheritance

class Human {
  final String name;
  Human(this.name);

  void say() {
    print('hi $name');
  }
}

enum Team { red, blue }

class Player extends Human {
  final Team team;

    // super enable child can communicate with parents
  // Player(super.name, this.team);
  Player({required this.team, required String name}) : super(name);
}

void main() {
  var player = Player(team: Team.blue, name: 'name');
}

mixins

생성자가 없는 클래스
클래스에 프로퍼티를 추가하거나 할 때 사용함

```dart
class Strong {
final double strength = 1500.99;
}

class QuickRunner {
void runQuick() {
print('run run run!');
}
}

class Player with Strong, QuickRunner {
final String team;
Player(this.team);
}

void main() {
var player = Player('team');
player.runQuick();
print(player.strength);
}
```</list</int,></string,>

[leetecode 오늘의 문제] 446. Arithmetic Slices II - Subsequence

박한결 — Sun, 7 Jan 2024 20:58:46 +0900

오늘의 문제

알고리즘 문제를 풀다보면 영어로 수학 용어를 알 필요를 종종 느끼게 된다. Arithmetic subsequences 는 등차수열이다.

이 문제에서는 nums 라는 배열에서 부분 등차 수열의 개수를 찾아야 하는데, 등차 수열은

적어도 세 개의 요소를 가지고 있으며,
연속하는 두 요소 사이의 차이가 동일하다는

것을 의미한다.

각 요소에 대한 defaultdict 초기화

배열의 각 요소에 대해, 특정 공차로 끝나는 부분 수열의 개수를 저장할 defaultdict을 생성한다.

    subsequences = [defaultdict(int) for _ in nums]
    total_count = 0

* defaultdict 를 사용하는 이유 - 존재하지 않는 키 처리

이 문제를 풀 때에는 공차( diff = nums[i] - nums[j] )를 계속해서 업데이트 해야 한다. 이때 defaultdic(int) 는 키가 존재하지 않는다면 기본값 0으로 초기화 하는데, 이 덕분에 키의 존재 여부를 확인하지 않고도 개수를 0부터 셀 수 있어서 편리하다.

즉, defaultdict 를 사용하지 않는다면 키가 있는지를 확인하고 초기화하는 로직을 추가할 필요가 없어서 효율적이다.

순회

    for i in range(len(nums)):
        for j in range(i):

공차 계산

            diff = nums[i] - nums[j]

diff는 nums[i] - nums[j]다.

nums[j]의 defaultdict에 이 차이가 이미 존재한다면, nums[i]를 추가하여 해당 부분 수열을 확장할 수 있음을 의미한다.

개수 업데이트

            count_at_j = subsequences[j][diff]
            count_at_i = subsequences[i][diff]
            subsequences[i][diff] = count_at_i + count_at_j + 1

각 쌍 (i, j)에 대해, diff에 대한 nums[i]의 맵의 개수를 업데이트 한다.

이 개수는 nums[j]에서 동일한 diff로 끝나는 부분 수열의 수(있는 경우)와 새로 형성된 부분 수열 [nums[j], nums[i]]의 합이다.

부분 수열 개수 세기

            total_count += count_at_j

nums[i]가 추가될 때 적어도 세 요소를 가진 유효한 등차 부분 수열의 수를 정확하게 반영하기 때문에 총 개수에 count_at_j를 추가한다.

count_at_i는 배열을 계속 처리하면서 추가적인 확장을 위한 잠재적인 부분 수열을 추적하는 데 사용한다.

부분 수열 확장
- (i, j) 쌍 (i > j)에서, nums[j]로 끝나는 기존 부분 수열을 nums[i]를 추가함으로써 확장
- 확장될 수 있는 부분 수열은 nums[i] - nums[j]와 같은 공차를 가진 수열
등차 부분 수열 계산
- 적어도 세 요소를 가진 부분 수열을 계산
- 따라서 (i, j) 쌍을 찾아 부분 수열을 확장할 수 있으면, 그 수열은 이미 적어도 두 요소(nums[j]에서 끝나는)를 가졌으며 이제 적어도 세 요소(nums[i]에서 끝나는)를 가질 것
count_at_j
- count_at_j에 저장된 개수는 nums[i]를 추가함으로써 확장될 수 있는 nums[j]로 끝나는 부분 수열의 수
- 이러한 각각의 개수는 적어도 세 요소를 가진 새로운 유효한 등차 부분 수열
count_at_i
- count_at_i는 특정 공차를 가진 nums[i]로 끝나는 모든 부분 수열(두 요소만 있는 수열 포함)
- (i, j) 쌍을 찾을 때마다 count_at_i를 증가시키므로, 이는 아직 유효하지 않은 부분 수열(즉, 적어도 세 요소가 없는)도 포함

[leetecode 오늘의 문제] 1235. Maximum Profit in Job Scheduling

박한결 — Sat, 6 Jan 2024 23:12:32 +0900

오늘의 문제 링크

오늘의 문제는 Job Scheduling 을 하면서, Maximum Profit 을 찾는 문제였다.

얼핏 봤을 때는 지난번에 풀었던 Interval Scheduling Algorithm 이 생각났다. Interval Scheduling Algorithm 은 일반적으로 각 간격과 관련된 이익을 고려하지 않고 겹치지 않는 간격(또는 작업)의 수를 최대화하는 것이었다.

하지만 이번 문제에서는 총 이익을 극대화해야 하므로 복잡도가 올라갔고, 다른 방법으로 접근해야 했다.

1. 종료 시간을 기준으로 정렬

Interval Scheduling Algorithm 이랑 비슷한 부분은 종료 시간을 기준으로 정렬하고 시작한다는 것

종료 시간을 기준으로 정렬하는 것은 현재 직업 이후에 선택할 수 있는 다음 직업을 효율적으로 찾을 수 있도록 해준다.

    jobs = sorted(zip(startTime, endTime, profit), key=lambda v: v[1])

2. 동적 프로그래밍(DP) 접근

DP 테이블 생성:
1. 테이블의 각 항목 dp[i]는 정렬된 job 목록에서 처음 i개의 job을 고려할 때 얻을 수 있는 최대 이익을 나타낸다.
각 job에 대한 결정:
- job을 제외하는 경우, 이익은 이전 job[i-1]과 동일하게 유지된다.
  - dp[i] = dp[i-1]
- job을 포함하는 경우, 해당 job의 이익을 추가해야 하며, 또한 현재 job의 시작 시간 전에 끝나는 충돌하지 않는 이전 job에서 얻을 수 있는 최대 이익을 추가해야 합니다.
최대 이익 계산: 각 job에 대해 이 두 가지 선택 사이에서 더 높은 이익을 주는 선택을 하여 최대 이익을 계산합니다.

    for i in range(1, n+1):
        # 옵션 1: 현재 job 을 제외
        excl = dp[i-1]

        # 옵션 2: 현재 job 을 포함
        incl = jobs[i-1][2]
        lastNonConflict = binarySearch(jobs, i-1)
        if lastNonConflict != -1:
            incl += dp[lastNonConflict + 1]

        # 현재 job 을 제외했을 때와 포함했을 때 이익이 최대화되는 경우를 dp[i]에 저장
        dp[i] = max(excl, incl)

(1) binarysearch

binarysearch를 사용하는 이유는 현재 작업과 시간상으로 겹치지 않으면서 가능한 가장 늦게 끝나는 이전 작업을 효율적으로 찾기 위해서다. job들이 종료 시간에 따라 정렬되어 있기 때문에, binarysearch는 현재 작업의 시작 시간 이전에 끝나는 가장 마지막 작업을 빠르게 찾는데 효율적인 방법이다.

binarysearch는 정렬된 리스트에서 특정 값을 찾을 때 효율적인 방법으로, 평균적으로 O(log n) 시간 복잡도를 가진다.
이는 각 작업을 처리할 때마다 모든 이전 작업을 확인하는 O(n) 시간 복잡도를 가지는 선형 탐색보다 훨씬 빠르다.

    def binarySearch(jobs, index):
        low, high = 0, index - 1
        while low <= high:
            mid = (low + high) // 2
            if jobs[mid][1] <= jobs[index][0]:
                if jobs[mid + 1][1] <= jobs[index][0]:
                    low = mid + 1
                else:
                    return mid
            else:
                high = mid - 1
        return -1

[Docker] VM vs Container

박한결 — Sat, 16 Dec 2023 21:37:27 +0900

VM ( Virtual Machine )

구조

VM은 하이퍼바이저를 사용하여 하드웨어를 가상화
- 하이퍼바이저는 가상화를 가능하게 하는 소프트웨어
- 이는 물리적 하드웨어와 가상 머신(VM) 사이에서 작동하며, 여러 개의 VM이 동일한 물리적 하드웨어 위에서 독립적으로 실행될 수 있도록 함.
- 각 VM은 완전한 운영 체제를 포함하며, 하이퍼바이저는 이러한 VM들이 하드웨어 자원을 효율적으로 공유하고 관리할 수 있도록 도움.
  - Type 1 (네이티브 하이퍼바이저): 이는 직접 하드웨어 위에 설치되며, 운영 체제 없이 독립적으로 작동 함.
    - ex. VMware ESXi, Microsoft Hyper-V, Xen
  - Type 2 (호스티드 하이퍼바이저): 이는 기존 운영 체제 위에 설치되며, 일반적인 애플리케이션처럼 작동함.
    - ex. VMware Workstation, Oracle VirtualBox
각 VM은 완전한 게스트 운영 체제, 필요한 라이브러리, 애플리케이션을 포함
이로 인해 각 VM은 물리적 하드웨어에서 독립적으로 작동

리소스 격리:

VM은 완전한 OS 격리를 제공
각 VM은 독립적인 환경에서 실행되므로, 다른 VM의 작업에 영향을 받지 않음

리소스 사용량:

VM은 전체 운영 체제를 실행하기 때문에 상대적으로 많은 리소스(디스크 공간, 메모리, CPU 시간)를 사용

장점:

완전한 OS 격리: 각 VM은 완전히 독립된 환경을 제공하고, 이로 인해 보안과 격리 측면에서 강력함
다양한 OS 지원: 다양한 운영 체제를 동시에 실행할 수 있음

단점:

리소스 사용량: 높은 리소스 사용량과 느린 시작 시간
스케일링 제한: 물리적 서버의 리소스 제한으로 인해 스케일링에 한계가 있음

Container

구조:

컨테이너는 OS 수준의 가상화를 제공
- 가상화는 물리적 하드웨어의 기능을 소프트웨어적으로 구현하고, 이를 여러 사용자나 환경에서 공유할 수 있게 하는 기술
- 상화를 통해 하나의 물리적 시스템을 여러 개의 독립된 가상 환경으로 분리할 수 있으며, 이는 서버, 스토리지, 네트워크 등 다양한 IT 자원에서 사용됨
  - 자원 효율성 증대: 여러 가상 머신이 하나의 물리적 서버에서 실행되어 하드웨어 자원을 최대한 활용할 수 있음
  - 유연한 리소스 관리: 가상 머신은 필요에 따라 쉽게 생성, 수정, 이동할 수 있어 리소스 관리가 유연해짐
  - 비용 절감: 물리적 인프라의 수를 줄임으로써 운영 비용과 유지 보수 비용을 절감할 수 있음
  - 격리 및 보안: 각 가상 머신은 서로 독립적으로 작동하여 격리되어 있기 때문에 보안성이 향상됨
  - 복구 및 이동성: 가상 머신은 쉽게 백업하고 다른 서버로 이동할 수 있어 재해 복구 및 데이터 관리가 용이함
컨테이너는 호스트 OS의 커널을 공유하지만, 프로세스, 파일 시스템, 네트워크 등을 격리

Namespace와 cgroup:

Namespace:
- 컨테이너는 Namespace를 사용하여 프로세스, 네트워크, 사용자 ID 등을 격리
- 이는 컨테이너가 호스트 OS와 동일한 커널을 사용하면서도 독립적인 환경을 유지할 수 있게 해줌
cgroup (Control Groups):
- cgroup은 리소스 사용량(메모리, CPU, 디스크 I/O 등)을 관리하고 제한
- 이를 통해 시스템의 각 컨테이너가 사용할 수 있는 리소스의 양을 제어할 수 있음

리소스 사용량:

컨테이너는 VM보다 훨씬 가벼우며, 더 적은 리소스를 사용하여 더 빠르게 시작하고 실행할 수 있음

장점:

효율적인 리소스 사용: 가벼운 구조로 인해 리소스를 효율적으로 사용함
빠른 시작 시간: 컨테이너는 VM에 비해 시작 시간이 훨씬 빠름
이식성: 애플리케이션과 그 의존성을 함께 패키징하기 때문에 다양한 환경에서 일관된 운영이 가능

단점:

보안 문제: 컨테이너는 격리 수준이 VM보다 낮아 보안 취약점이 될 수 있음
호스트 OS 의존성:
- 공유된 커널 구조: 컨테이너는 호스트 운영 체제의 커널을 공유. 이는 컨테이너가 호스트 OS에 설치된 커널을 기반으로 실행된다는 것을 의미함. 따라서, 컨테이너는 호스트 OS와 같은 유형의 커널을 사용 해야 함.
- 이식성의 제한: 호스트 OS의 커널을 공유한다는 점은 컨테이너가 특정 OS에 종속될 수 있음을 의미함. 예를 들어, 리눅스 기반 컨테이너는 리눅스 커널을 사용하는 호스트에서만 실행될 수 있음. 이는 다른 운영 체제에서의 실행을 제한 .
- 보안 측면의 영향: 컨테이너가 호스트 OS의 커널과 직접적으로 상호작용한다는 점은 보안상의 고려사항을 낳음. 하나의 컨테이너에서 발생한 취약점이 호스트 OS의 커널에 영향을 미칠 수 있으며, 이는 다른 컨테이너들에도 영향을 줄 수 있음.

[Kubernetes] Auto Healing / Auto Scaling / HPA / Probe / Health Checks

박한결 — Sat, 16 Dec 2023 21:11:54 +0900

1. Auto Healing

1) 개념

Kubernetes 클러스터 내에서 실행되는 컨테이너나 노드가 실패했을 때, 시스템이 자동으로 이를 감지하고 복구하는 기능

2) 사용

애플리케이션이 실패하거나 예상치 못한 오류가 발생했을 때 사용

3) 작동 방식

Kubernetes의 Health Checks를 통해 애플리케이션의 상태를 지속적으로 모니터링
문제가 감지되면, 시스템은 자동으로 문제가 있는 컨테이너를 재시작하거나 교체

(1) Health Checks

Health Checks는 Kubernetes 클러스터 내에서 실행 중인 컨테이너의 상태를 모니터링하고, 문제가 발생했을 때 적절한 조치를 취하는 데 중요한 역할을 함
주로 두 가지 유형의 프로브(Probe)를 사용 - Liveness Probe, Readiness Probe
- "Probe"는 컨테이너의 상태를 체크하는데 사용되는 진단 도구
- 이를 통해 Kubernetes는 컨테이너가 정상적으로 작동하고 있는지, 그리고 요청을 처리할 준비가 되었는지를 확인
- Probe의 설정은 Kubernetes의 Pod 설정 파일 안에서 정의되며, HTTP 요청, TCP 소켓 체크, 또는 특정 커맨드 실행을 통해 구성될 수 있음
  - Liveness Probe
    - 컨테이너가 정상적으로 작동하고 있는지 확인
    - 만약 컨테이너가 죽었거나 응답하지 않는 상태가 되면, Kubernetes는 이를 감지하고 컨테이너를 자동으로 재시작
    - ex. 컨테이너 내부의 애플리케이션이 데드락에 빠져 응답하지 않는 경우, Liveness Probe가 이를 감지하고 컨테이너를 재시작하여 문제를 해결할 수 있음
  - Readiness Probe
    - 컨테이너가 요청을 처리할 준비가 되었는지 확인
    - 이는 컨테이너가 시작되고 네트워크 트래픽을 수신할 준비가 되었는지를 판단하는 데 사용
    - ex. 애플리케이션이 시작되어도 초기화 과정이 필요한 경우, Readiness Probe는 초기화가 완료될 때까지 트래픽을 해당 컨테이너로 보내지 않음
  - Startup Probe
    - 시작 시간이 긴 컨테이너가 성공적으로 시작되었는지 확인하는 데 사용
    - Liveness Probe와 Readiness Probe가 너무 일찍 개입하여 컨테이너를 잘못 재시작하는 것을 방지
Health Checks의 구성은 YAML 파일 내에서 컨테이너 스펙에 정의되며, HTTP 요청, TCP 소켓 체크, 또는 특정 커맨드 실행을 통해 수행

4) 구현 방식

Liveness와 Readiness 프로브를 설정하여 컨테이너의 상태를 확인

2. Auto Scaling

1) 개념

애플리케이션의 부하에 따라 자동으로 컨테이너의 수를 조정하는 기능
수요에 따라 리소스를 적절하게 할당하여 성능을 최적화

2) 사용

트래픽이나 작업 부하가 증가하거나 감소할 때 사용

3) 작동 방식

Metrics Server를 사용하여 클러스터의 리소스 사용량을 모니터링
- 클러스터 내부의 리소스 사용량 데이터(예: CPU, 메모리 사용량)를 수집하는 쿠버네티스의 클러스터 수준 모니터링 툴
  - 이 데이터는 Horizontal Pod Autoscaler(HPA)와 같은 자동 스케일링 시스템에서 Pod의 수를 동적으로 조절하는 데 사용
  - 클러스터의 성능 모니터링과 자동 스케일링을 위해 사용
- 클러스터 관리자가 클러스터의 리소스 사용 패턴을 이해하고 최적화하는 데 도움을 줌
설정된 임계값에 따라, 필요시 컨테이너의 수를 늘리거나 줄임

4) 구현 방식

Metrics Server는 클러스터의 모든 노드에 설치된 kubelet을 통해 메트릭을 수집
- Kubernetes 클러스터의 각 노드에서 실행되는 주요 구성 요소
- 클러스터의 각 워커 노드에서 실행되는 에이전트 역할을 수행
- 클러스터의 마스터 노드로부터 받은 지시에 따라 각 노드에서 컨테이너를 실행하고 관리하는 역할
- 주요 기능
  1. Pod 스펙 실행: kubelet은 API 서버로부터 Pod에 대한 스펙(명세)을 받아, 해당 스펙에 정의된 컨테이너를 실행
    1. 이 스펙에는 컨테이너 이미지, 포트, 볼륨 등이 포함될 수 있음
  2. 컨테이너 상태 모니터링: kubelet은 실행 중인 컨테이너의 상태를 주기적으로 체크하고, 문제가 발생하면 재시작하는 등의 조치를 취함
  3. 리소스 관리: kubelet은 노드의 사용 가능한 리소스(예: CPU, 메모리)를 관리하고, 각 Pod에 할당할 리소스 양을 조정
  4. 노드 상태 보고: kubelet은 정기적으로 노드의 상태를 Kubernetes API 서버에 보고함
    - 이 정보에는 노드의 리소스 사용량, 네트워크 상태, 시스템 정보 등이 포함됨
  5. 헬스 체크 수행: kubelet은 Liveness Probe와 Readiness Probe를 통해 컨테이너의 건강 상태를 체크 함
  6. 로그 및 메트릭 수집: kubelet은 컨테이너의 로그를 수집하고, 성능 메트릭을 모니터링하여 필요시 중앙 집중식 로깅 시스템이나 모니터링 시스템에 전달
- 중요성
  1. 노드 수준의 오케스트레이션: kubelet은 각 노드에서 컨테이너의 생명 주기를 관리하는 핵심 역할
    - 이는 클러스터 전체의 오케스트레이션을 가능하게 하는 기반입니다.
  2. 자동화된 클러스터 관리: kubelet의 자동화된 기능은 Kubernetes 클러스터의 관리를 단순화하고, 효율적인 운영을 지원함
  3. 고가용성 및 신뢰성 보장: kubelet은 노드와 컨테이너의 상태를 지속적으로 모니터링하고, 필요한 경우 적절한 조치를 취함으로써 클러스터의 고가용성과 신뢰성을 보장함

kubelet은 각 노드에서 실행 중인 컨테이너의 리소스 사용량을 모니터링하고 이를 Metrics Server에 보고
Horizontal Pod Autoscaler(HPA)를 사용하여 부하에 따라 Pod의 수를 자동으로 조절
- Horizontal Pod Autoscaler (HPA)는 Kubernetes에서 자동 스케일링을 구현하는 중요한 컴포넌트
- HPA는 클러스터 내의 Pod 수를 자동으로 조절하여, 애플리케이션의 부하에 따라 적절한 수의 Pod 인스턴스를 유지하도록 함
- 작동 원리
  1. 메트릭 모니터링
    - HPA는 주로 CPU 사용량, 메모리 사용량과 같은 메트릭을 기반으로 동작
    - 메트릭은 Kubernetes 클러스터 내부의 Metrics Server에서 수집
  2. 스케일링 결정
    - 설정된 메트릭 임계값에 따라, HPA는 Pod의 수를 증가시키거나 감소시킴
    - ex. CPU 사용량이 설정된 임계값을 초과하면, HPA는 더 많은 Pod를 생성하여 부하를 분산시킴
  3. 자동 조절
    - 부하가 감소하고 임계값 아래로 떨어지면, HPA는 불필요한 Pod를 줄여 리소스를 효율적으로 사용하도록 함
- 구성
  - Kubernetes의 YAML 파일을 통해 이루어짐
    - 스케일링 대상(예: Deployment), 사용할 메트릭, 그리고 임계값 설정이 포함
  - 사용자는 HPA에 대한 최소 및 최대 Pod 수를 설정할 수 있으며, 이는 HPA가 생성하거나 제거할 수 있는 Pod의 수를 제한함
- 장점
  1. 자원 효율성: 부하가 적은 시간에는 자원을 절약할 수 있으며, 부하가 높은 시간에는 자동으로 리소스를 확장하여 애플리케이션의 성능을 유지
  2. 사용자 개입 최소화: 애플리케이션의 부하에 따라 자동으로 스케일링이 이루어지므로, 지속적인 관리나 개입이 필요하지 않음
  3. 유연한 대응: 트래픽 변동이나 예상치 못한 부하 증가에 대응하여 애플리케이션의 가용성을 유지할 수 있음

3. 장단점

1) 장점

자원의 효율적 사용과 높은 가용성.
사용자 개입 없이 시스템이 자동으로 관리됨.
부하에 따른 유연한 리소스 관리 가능.

2) 단점

복잡한 설정과 관리 필요.
부적절한 설정은 리소스 낭비나 성능 저하를 일으킬 수 있음.
자동 스케일링은 예측하지 못한 트래픽 변동에 빠르게 반응하지 못할 수도 있음.

[Kubernetes][CKA] Kube Proxy

박한결 — Wed, 13 Dec 2023 02:31:18 +0900

Within Kubernetes Cluster, every pod can reach every other pod, this is accomplish by deploying a pod networking cluster to the cluster.

Kube-Proxy is a process that runs on each node in the kubernetes cluster.

pod network ( service cannot connected to pod network because it is not real - no interface and no process - only in the kubernetes memory => how to use ? => use kube-proxy )

every pod can reach each pod

all the pods are connected

able to communicate to to each bods

kube-proxy

process ruunnig each nodes

find new services

create rules and forward it to the backend ports

Kube-Proxy는 쿠버네티스 클러스터 내의 네트워크 트래픽을 관리하고, 파드 간의 통신을 가능하게 하는 핵심적인 역할을 한다. 각 노드에서 실행되는 이 프로세스는 서비스와 파드 사이의 통신을 원활하게 하며, 클러스터 내에서 안정적인 네트워크 연결을 유지하는 데 중요한 기능을 수행한다.

Kube-Proxy의 역할

Kube-Proxy는 쿠버네티스 클러스터의 각 노드에서 실행되는 프로세스
이는 파드 간의 네트워킹을 가능하게 하는 주요 구성 요소 중 하나

파드 네트워킹

쿠버네티스 클러스터 내에서, 모든 파드는 다른 모든 파드에 접근할 수 있어야 하고, 이를 위해 파드 네트워킹 클러스터가 배포됨
서비스는 실제로 존재하지 않는 (인터페이스나 프로세스가 없는) 개념이기 때문에 직접 파드 네트워크에 연결될 수 없음. 이는 쿠버네티스의 메모리 내에서만 존재함.

Kube-Proxy의 작동 방식

연결 방법: Kube-Proxy를 사용하여 서비스가 파드 네트워크에 접근할 수 있도록 함. Kube-Proxy는 네트워크 트래픽을 적절한 파드로 전달하는 규칙을 생성.
새로운 서비스 탐색: Kube-Proxy는 클러스터 내의 새로운 서비스를 찾아내고, 이들에 대한 네트워크 통신 규칙을 만듬.
규칙 생성 및 전달: 생성된 규칙을 통해 트래픽을 파드의 백엔드 포트로 전달함.

파드 간 통신

모든 파드는 Kube-Proxy를 통해 서로 연결되어 있으며, 이를 통해 서로 통신할 수 있음.

실습 https://github.com/kodekloudhub/certified-kubernetes-administrator-course/blob/master/docs/02-Core-Concepts/10-Kube-Proxy.md

[Kubernetes][CKA] Kubelet

박한결 — Wed, 13 Dec 2023 02:19:56 +0900

Kubelet is the sole point of contact for the kubernetes cluster
- The kubelet will create the pods on the nodes, the scheduler only decides which pods goes where.
- register node
- create pods
- monitor node and pods

Kubelet은 쿠버네티스 클러스터와 개별 노드 간의 소통을 담당하며, 파드의 생명주기 관리와 노드 상태의 모니터링을 수행 한다.

Kubelet의 역할

Kubelet은 쿠버네티스 클러스터와 노드 간의 유일한 접점
Kubelet은 노드에 파드를 생성하며, 스케줄러는 파드가 어느 노드에 배치될지만 결정

노드 등록

Kubelet은 각 노드를 클러스터에 등록하는 역할
- 이 과정에서 노드의 정보(하드웨어 사양, IP 주소 등)가 클러스터에 제공됨

파드 생성

Kubelet은 스케줄러로부터 배치 결정을 받아 실제로 노드에 파드를 생성
- 이는 컨테이너 이미지를 가져오고, 파드의 네트워크 및 볼륨을 설정하는 등의 작업을 포함

노드 및 파드 모니터링

Kubelet은 노드와 그 위에 실행 중인 파드의 상태를 지속적으로 모니터
- 이는 노드의 건강 상태, 파드의 실행 상태, 리소스 사용량 등을 포함
또한, 노드나 파드에 문제가 발생하면 이를 복구하거나 클러스터 관리자에게 알리는 역할

실습 https://github.com/kodekloudhub/certified-kubernetes-administrator-course/blob/master/docs/02-Core-Concepts/09-Kubelet.md

[Kubernetes][CKA] Kube Scheduler

박한결 — Wed, 13 Dec 2023 02:10:34 +0900

kube-scheduler is responsible for scheduling pods on nodes.

The kube-scheduler is only responsible for deciding which pod goes on which node.
It doesn't actually place the pod on the nodes, that's the job of the kubelet.

why do you need a scheduler?
- filter nodes
- rank nodes

resource requirements and limits
taints and tolerations
node selectors/affinity

Kube-Scheduler는 쿠버네티스 클러스터에서 파드의 효율적인 배치를 담당하는 중요한 구성 요소다.

이는 노드의 자원 가용성, 파드의 요구사항, taint 및 toleration, node selector 및 affinity 등 다양한 요소를 고려하여 파드가 가장 적합한 노드에 배치되도록 한다.

이러한 과정을 통해 클러스터의 자원 활용도를 최적화하고, 파드의 성능과 안정성을 보장한다.

개요

kube-scheduler는 파드(Pods)를 노드(Nodes)에 스케줄링한다.
kube-scheduler의 역할은 어떤 파드가 어떤 노드에 위치할지 결정하는 것이다. 실제로 파드를 노드에 배치하는 것은 kubelet의 역할이다.

스케줄러가 필요한 이유

filter nodes: 적합한 노드를 선택하기 위해 여러 기준을 사용하여 노드를 필터링
rank nodes: 필터링된 노드 중에서 가장 적합한 노드를 선정하기 위해 랭킹을 매김
resource requirements and limit: 각 파드의 자원 요구사항과 제한을 고려하여 적절한 노드를 선택

Taints(테인트)와 Tolerations(톨러레이션)

taints: 특정 노드에 파드가 배치되는 것을 제한하기 위해 노드에 설정할 수 있는 속성
tolerations: 파드가 테인트된 노드에도 배치될 수 있게 하는 파드의 속성

노드 셀렉터/친화성

node selector: 파드가 배치될 수 있는 노드를 레이블을 통해 지정
node affinity: 노드 셀렉터보다 더 세밀한 조건을 설정하여 파드가 배치될 노드를 지정

실습 https://github.com/kodekloudhub/certified-kubernetes-administrator-course/blob/master/docs/02-Core-Concepts/08-Kube-Scheduler.md

[Kubernetes][CKA] Kube Controller Manager

박한결 — Wed, 13 Dec 2023 01:48:38 +0900

Kube Controller Manager manages various controllers in kubernetes.
- In kubernetes terms, a controller is a process that continuously monitors the state of the components within the system and works towards bringing the whole system to the desired functioning state.

Node Contoller responsible for monitoring(using kube-apiserver) the state of the Nodes and taking necessary actions to keep the application running

Replication Controller is responsible for monitoring the status of replicasets and ensuring that the desired number of pods are avaliable at all time within the set.

There are may more controllers available within kubernetes.

개요

Kube Controller Manager는 쿠버네티스 내의 다양한 컨트롤러를 관리
쿠버네티스에서 컨트롤러란 시스템 내 구성 요소들의 상태를 지속적으로 모니터링하고 전체 시스템을 원하는 상태로 유지하기 위해 작동하는 프로세스

노드 컨트롤러

역할: 노드의 상태를 모니터링하고(주로 kube-apiserver를 사용하여) 애플리케이션이 지속적으로 실행되도록 조치
기능:
- 노드의 상태를 관찰
- 문제 상황을 해결

레플리케이션 컨트롤러

역할: 레플리카셋의 상태를 모니터링하고 집합 내에서 원하는 수의 파드가 항상 유지되도록 함
기능:
- 레플리카셋의 상태 관찰
- 파드 수를 원하는 수준으로 유지

기타 컨트롤러

쿠버네티스 내에는 여러 가지 다른 컨트롤러들이 존재함
이 컨트롤러들은 클러스터의 다양한 측면을 관리하며, 클러스터의 건전성과 효율성을 유지하는 데 중요한 역할을 함

실습

https://github.com/kodekloudhub/certified-kubernetes-administrator-course/blob/master/docs/02-Core-Concepts/07-Kube-Controller-Manager.md

[Kubernetes][CKA] Kube-API Server

박한결 — Wed, 13 Dec 2023 01:09:54 +0900

kubectl ( kube-apiserver - ETCD Cluster - kuber-api server) or api
kube scheduler - kube-apiserver - kubelet ( worker nodes )
kubectl is center of all the different takes needs to be done to make a change in the cluster
kube-api server
- authenticate user
- validate
- retrieve data
- update ETCD
- scheduler
- kubelet
kube-apiserver.service options
kubeadmin

kube-api 서버의 중심 역할

kube-apiserver는 etcd 데이터 저장소와 직접 상호 작용하는 유일한 구성 요소
- kube-scheduler, kube-controller-manager 및 kubelet과 같은 다른 구성 요소는 API 서버를 사용하여 클러스터의 해당 영역에서 업데이트
kubectl과의 관계:
- kubectl은 클러스터에서 변경 사항을 만들기 위해 필요한 모든 작업의 중심에 있다. 이는 kube-api 서버를 통해 실행된다.
- kubectl은 클러스터와 상호 작용하는 데 중심적인 도구이지만, 주로 사용자가 kube-apiserver에 명령을 보내는 커맨드 라인 도구
- 실제로 이러한 명령을 처리하고 쿠버네티스의 다른 구성 요소와 상호 작용하는 것은 kube-apiserver
구조:
- kubectl → kube-apiserver → ETCD 클러스터
- API 직접 접근

kube-api 서버의 기능

사용자 인증: 클러스터에 요청을 보내는 사용자의 신원을 확인
요청 검증: 요청된 작업이 쿠버네티스 규칙과 정책을 준수하는지 검증
데이터 검색: 클러스터의 현재 상태나 구성 데이터를 검색
ETCD 업데이트: 클러스터의 상태 변경 사항을 ETCD에 반영

kube-scheduler와 kubelet의 연결

kube-scheduler: kube-apiserver를 통해 클러스터의 자원 할당 및 스케줄링을 관리
kubelet: 워커 노드에서 실행되며 kube-apiserver로부터 명령을 받아 노드에서 컨테이너를 실행하고 관리
구조: kube-scheduler → kube-apiserver → kubelet (워커 노드)

kube-apiserver.service 옵션

설정 가능한 옵션:
- kube-apiserver는 다양한 서비스 옵션을 통해 구성 및 관리할 수 있음.
- 이러한 옵션을 통해 클러스터의 보안, 성능 및 접근성을 조정할 수 있음.

Kubeadm과의 관계

Kubeadm:
- 쿠버네티스 클러스터를 구축하고 관리하는 데 사용되는 도구
- kube-api 서버를 포함한 쿠버네티스의 핵심 구성 요소를 설정하는 데 도움됨

실습 https://github.com/kodekloudhub/certified-kubernetes-administrator-course/blob/master/docs/02-Core-Concepts/06-Kube-API-Server.md