k8s - 나의 실패한 Pod 배치전략

 

노드를 3개를 추가했고

 

하나의 노드는 1. 일반적인 백 관련된 서비스만                         ............ (노드1)

또 하나의 노드는 2. 공통적인 백 관련된 서비스를 배치하고     ............ (노드2)

마지막 하나에 프론트 관련된 내용만 서비스를 배치하려고 생각했다. . (노드3)

 

관리 편의성으로 비슷한 역할을 하는 것끼리 묶어 두면 편하지 않을까 하는 생각에..ㅠ

 

nodeSelector:
	diskname: front

 

 

POD가 하나만 존재할 때는 상관없지만.. 하나 이상일 때 즉,  두 개의 파드는 서로 다른 노드 속에 있는 것이 이상적라는 생각이..들었다. 그래야지 노드가 죽어도 다른 노드에 있는 친구를 통해 고가용성을 보장해 줄테니..

 

 

노드하나에 죽으면 아무리  POD가 많아도 딱 끝!!

nodeSelector을 관련 내용을 제외해도 계속 "같은 노드"에만 쌓인다...아따....어쩌다가.. 반반씩 갈라치기가 되었다.

 

서버가 많다고 해서 한 사람의 품질이 올라가지는 않는다... 품질은.. 스케일-업을 해야 한다고 본다. ㅎ

서버가 많다는 건 "동시"에  리퀘스트를  처리 할 수 있다는 거다. 

 

뭐 암튼..다시 두개로 scale 했더니.. 아따.....인텔리하지 못하네..(같은노드)

 

암튼 nodeSelector는 되도록 쓰지 말고 쿠버에게 맡기자!!!

 

## 11.07 찾아보니. ㅎㅎ

다른 노드에 배치 할 수 있는 전략이 있네. 

podAntiAffinity 

 

## 11.08 찾아보니. ㅎㅎ

저 친구는 사용하는 법이 제법 난이도가 있는 친구였는데 아래 친구는 간단스 하다.

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: f-lecture

 

topologyKey를 기준으로 배포한다. 

기준이 되는 키는 노드 레이블에 지정이 되어 있어야 한다.(kubectl get nodes --show-labels)

지정이 되어 있지 않으면 배포정책에서 제외된다.(by Pass)

 

각 노드마다 hostname은 다르기 때문에 같은 노드에 배포 되지 않는 정책이다.

디테일하게 보자면 다른 정책들로 인해서 다양한 케이스가 만들어 질 수 있다.

 

먼저  replicas와 노드수가 같다면 정확히 갈라치기가 된다. 

여기서 replicas가 더 키우면  파드의 배치는는  "2:1 혹은 1:2"이 된다.

단, ScheduleAnyway 일때만 진행이 되는 부분이고 DoNotSchedule 지정 하면 정책이 맞지 않아서 말처럼 스케쥴을 진행하지 않는다.

 

자세한 내용은 원문을 참고하면 될 것 같고 나처럼 단순하게 서로 다른 노드에 배포 시키려는 목표는 위에 작성된  설정만 하면 된다.!!

 

https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/

Pod Topology Spread Constraints

 

그래도 LB의 역할을 할 수 있도록 인그레스 콘트롤러 두 대 배치 했고 프론트만 다른 노드에 배치 했다.

Oauth도 아르메리아 webflux 이기에 하나로 충분!!

 

 주 서비스인 동영상을 CDN으로 쓰기 때문에  너끈하다!!