앞으로의 스터디 내용은 <Kubernetes in Action>을 기반으로 진행합니다.
자세한 내용은, 해당 책을 확인해주세요!
http://www.yes24.com/Product/Goods/89607047
스케줄링 심화란
파드 스펙 내 노드 셀렉터 지정 방식 외에도 파드가 스케줄링될 위치를 조정하는 추가적인 메커니즘
1. 노드 테인트와 파드 톨러레이션
1.1. 테인트는 기존의 파드를 수정하지 않는다. 노드에 테인트를 추가하면 파드가 특정 노드에 배포되지 않는다.
1.2. 테인트된 노드에 배포할 파드는 테인트된 노드를 사용하게 선택한다.
2. 노드 셀렉터와 노드 어피니티
2.1. 특정 정보를 파드에 추가해 파드가 스케줄링 가능한 노드인지의 여부를 선택한다. 즉, 기존 파드를 수정한다.
2.2. 파드에 배포할 노드를 명시적으로 지정한다.
테인트와 톨러레이션을 사용한 파드 실행 제한
본래는 k describe node master.k8s를 실행해 마스터 노드의 테인트를 확인하고자 했으나, 미니쿠베 환경에서는 미니쿠베 단독 노드만 존재하므로 해당 테인트 확인이 어려워 실습을 넘어가기로 한다.
0. 테인트와 톨러레이션
- 테인트 = 얼룩. 표식. 노드에 표식을 남기다.
- 톨러레이션 = 허용. 파드가 표식을 가진 노드를 허용한다.
https://kubernetes.io/ko/docs/concepts/scheduling-eviction/taint-and-toleration/
테인트(Taints)와 톨러레이션(Tolerations)
노드 어피니티는 노드 셋을 (기본 설정 또는 어려운 요구 사항으로) 끌어들이는 파드의 속성이다. 테인트 는 그 반대로, 노드가 파드 셋을 제외할 수 있다. 톨러레이션 은 파드에 적용되며, 파드
kubernetes.io
1. 마스터 노드의 테인트
1.1. 테인트의 구성 : <key>=<value>:<effect>
1.1.1. EX) node-role.kubernetes.io/master: NoSchedule
- key = node-role.kubernetes.io/master
- value = null
- effect = NoSchedule >> 파드가 이 테인트를 허용하지 않는 한 마스터 노드에 스케줄링 불가
2. 파드의 톨러레이션 표시
$ k describe po kube-proxy-gqm9x -n kube-system
...
Node-Selectors: kubernetes.io/os=linux
Tolerations: op=Exists
node.kubernetes.io/disk-pressure:NoSchedule op=Exists
node.kubernetes.io/memory-pressure:NoSchedule op=Exists
node.kubernetes.io/network-unavailable:NoSchedule op=Exists
node.kubernetes.io/not-ready:NoExecute op=Exists
node.kubernetes.io/pid-pressure:NoSchedule op=Exists
node.kubernetes.io/unreachable:NoExecute op=Exists
node.kubernetes.io/unschedulable:NoSchedule op=Exists
Events: <none>2.1. kube-proxy 파드는 마스터 노드에서도 실행될 수 있도록 적절한 톨러레이션을 포함한다.
2.2. 파드 톨러레이션에 등장하는 등호는, 노드 테인트에는 등장하지 않는다.
2.3. kubectl은 테인트나 톨러레이션 값이 null일 때 표시를 다르게 진행했었으나 현재는 같게 표시한다.
3. 테인트 효과 이해하기
3.1. NoSchedule : 파드가 테인트를 허용하지 않는 경우, 파드가 노드에 스케줄링되지 않음
3.2. PreferNoSchedule : 스케줄러가 파드를 노드에 스케줄링하지 않으려 하지만, 다른 대안이 없을 경우 해당 노드에 스케줄링
3.3. NoExecute : 테인트를 노드에 추가하면, 해당 노드에 이미 실행 중이지만 해당 테인트를 허용하지 않는 파드는 노드에서 제거
3.3.1. 노드에서 이미 실행 중인 파드에도 영향을 준다는 특징을 보유
4. 사용자 정의 테인트 추가
4.1 사용 예시
4.1.1. 프로덕션 워크로드와 비-프로덕션 워크로드의 클러스터 내 노드 간 분리
4.1.2. kubectl taint node node1.k8s node-type=production:NoSchedule >> node "node1.k8s" tainted
5. 파드에 톨러레이션 추가
$ cat production-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: prod
spec:
replicas: 5
selector:
matchLabels:
app: prod
template:
metadata:
labels:
app: prod
spec:
containers:
- args:
- sleep
- "99999"
image: busybox
name: main
tolerations:
- key: node-type
operator: Equal
value: production
effect: NoSchedule$ k create -f production-deployment.yaml
deployment.apps/prod created5.1. node-type=non-production:NoSchedule과 같은 테인트를 비 프로덕션 노드에 추가하면, 프로덕션 파드가 비 프로덕션 노드에 추가되지 않을 것.
**실습의 경우 프로덕션 노드, 비-프로덕션 노드 2종류가 필요하지만, 실습을 미니쿠베 단일 노드 환경에서 작업하므로 이론만 파악
6. 테인트와 톨러레이션 활용 방안 이해
6.1. 테인트와 톨러레이션의 특성
6.1.1. 노드는 하나 이상의 테인트를 가질 수 있다
6.1.1.1. 테인트는 키와 효과를 반드시 가지고, 값은 꼭 필요로 하지는 않는다
6.1.2. 파드는 하나 이상의 톨러레이션을 가질 수 있다
6.1.2.1. 톨러레이션은 Equals 연산자를 지정해 특정한 값을 허용한다.
6.1.2.2. 톨러레이션은 Exists 연산자를 지정해 특정 테인트 키에 여러 값을 허용한다.
6.2. 스케줄링 내 테인트 및 톨러레이션 활용
6.2.1. 테인트의 효과 - 새 파드의 스케줄링 방지 / 비선호 노드 정의 / 기존 파드 제거
6.2.2. 경우 1) 여러 파티션으로 분할해 개발팀이 원하는 노드에만 파드를 스케줄링
6.2.3. 경우 2) 일부 노드에만 특수한 하드웨어를 제공해, 일부 파드만 해당 하드웨어를 사용
6.3. 노드 실패 후 리스케줄링까지의 시간 간격 설정
6.3.1. 리스케줄링 대기 경우
6.3.1.1. 파드를 실행 중인 노드가 준비되지 않은 경우
6.3.1.2. 파드를 실행 중인 노드가 도달할 수 없는 경우
6.3.2. 리스케줄링 시간 간격 설정 방법
6.3.2.1. 톨러레이션을 사용해 다른 노드로 파드를 다시 스케줄링하기 전 대기 시간을 지정
$ k get po prod-557f48f78-78cff -o yaml
...
tolerations:
...
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
...6.3.2.2. yaml 해설 : not-ready, unreachable 상태를 300초간 허용. 미준비/미도달 상태를 감지하면 300초 대기 후 다른 노드로 다시 스케줄링.
6.3.2.3. 톨러레이션 별도 미정의 파드는 해당 톨러레이션이 과거에는 자동 추가됨. 지연 시간을 조절하기 위해서는 파드 스펙 내 해당 톨러레이션을 명시 후 지연 시간을 변경해야 함.
[테인트 기반 축출, Taint based Evictions]
앞에서 우리는 노드에서 이미 실행 중인 파드에 영향을 주는 NoExecute 테인트 이펙트를 다음과 같이 언급했다.
- 테인트를 용인하지 않는 파드는 즉시 축출된다.
- 톨러레이션 명세에 tolerationSeconds 를 지정하지 않고 테인트를 용인하는 파드는 계속 바인딩된다.
- tolerationSeconds 가 지정된 테인트를 용인하는 파드는 지정된 시간 동안 바인딩된 상태로 유지된다.
참고: 쿠버네티스는 사용자나 컨트롤러에서 명시적으로 설정하지 않았다면, 자동으로 node.kubernetes.io/not-ready 와 node.kubernetes.io/unreachable 에 대해 tolerationSeconds=300 으로 톨러레이션을 추가한다. 자동으로 추가된 이 톨러레이션은 이러한 문제 중 하나가 감지된 후 5분 동안 파드가 노드에 바인딩된 상태를 유지함을 의미한다.
https://kubernetes.io/ko/docs/concepts/scheduling-eviction/taint-and-toleration/
테인트(Taints)와 톨러레이션(Tolerations)
노드 어피니티는 노드 셋을 (기본 설정 또는 어려운 요구 사항으로) 끌어들이는 파드의 속성이다. 테인트 는 그 반대로, 노드가 파드 셋을 제외할 수 있다. 톨러레이션 은 파드에 적용되며, 파드
kubernetes.io
노드 어피니티를 통한 파드 유인
1. 노드 어피니티와 노드 셀렉터 비교
1.1. 노드 어피니티 과거 = 초기 쿠버네티스 파드 스펙 노드 셀렉터
1.2. 노드 어피니티
1.2.1. 기능 소개
1.2.1.1. 각 파드가 고유 노드 어피니티 규칙 정의
1.2.1.2. 파드가 지켜야 하는 필수 요구 사항 및 선호도를 지정
[어피니티(affinity)와 안티-어피니티(anti-affinity)]
nodeSelector 는 파드를 특정 레이블이 있는 노드로 제한하는 매우 간단한 방법을 제공한다. 어피니티/안티-어피니티 기능은 표현할 수 있는 제약 종류를 크게 확장한다. 주요 개선 사항은 다음과 같다.
1. 어피니티/안티-어피니티 언어가 더 표현적이다. 언어는 논리 연산자인 AND 연산으로 작성된 정확한 매칭 항목 이외에 더 많은 매칭 규칙을 제공한다.
2. 규칙이 엄격한 요구 사항이 아니라 "유연한(soft)"/"선호(preference)" 규칙을 나타낼 수 있기에 스케줄러가 규칙을 만족할 수 없더라도, 파드가 계속 스케줄되도록 한다.
3. 노드 자체에 레이블을 붙이기보다는 노드(또는 다른 토폴로지 도메인)에서 실행 중인 다른 파드의 레이블을 제한할 수 있다. 이를 통해 어떤 파드가 함께 위치할 수 있는지와 없는지에 대한 규칙을 적용할 수 있다.
어피니티 기능은 "노드 어피니티" 와 "파드 간 어피니티/안티-어피니티" 두 종류의 어피니티로 구성된다. 노드 어피니티는 기존 nodeSelector 와 비슷하지만(그러나 위에서 나열된 첫째와 두 번째 이점이 있다.), 파드 간 어피니티/안티-어피니티는 위에서 나열된 세번째 항목에 설명된 대로 노드 레이블이 아닌 파드 레이블에 대해 제한되고 위에서 나열된 첫 번째와 두 번째 속성을 가진다.
[노드 어피니티]
노드 어피니티는 개념적으로 nodeSelector 와 비슷하다 -- 이는 노드의 레이블을 기반으로 파드를 스케줄할 수 있는 노드를 제한할 수 있다.
여기에 현재 requiredDuringSchedulingIgnoredDuringExecution 와 preferredDuringSchedulingIgnoredDuringExecution 로 부르는 두 가지 종류의 노드 어피니티가 있다. 전자는 파드가 노드에 스케줄되도록 반드시 규칙을 만족해야 하는 것(nodeSelector 와 비슷하나 보다 표현적인 구문을 사용해서)을 지정하고, 후자는 스케줄러가 시도하려고는 하지만, 보증하지 않는 선호(preferences) 를 지정한다는 점에서 이를 각각 "엄격함(hard)" 과 "유연함(soft)" 으로 생각할 수 있다.
이름의 "IgnoredDuringExecution" 부분은 nodeSelector 작동 방식과 유사하게 노드의 레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 그 노드에서 동작한다는 의미이다. 향후에는 파드의 노드 어피니티 요구 사항을 충족하지 않는 노드에서 파드를 제거한다는 점을 제외하고는 requiredDuringSchedulingIgnoredDuringExecution 와 동일한 requiredDuringSchedulingRequiredDuringExecution 를 제공할 계획이다.
따라서 requiredDuringSchedulingIgnoredDuringExecution 의 예로는 "인텔 CPU가 있는 노드에서만 파드 실행"이 될 수 있고, preferredDuringSchedulingIgnoredDuringExecution 의 예로는 "장애 조치 영역 XYZ에 파드 집합을 실행하려고 하지만, 불가능하다면 다른 곳에서 일부를 실행하도록 허용"이 있을 것이다. 노드 어피니티는 PodSpec의 affinity 필드의 nodeAffinity 필드에서 지정된다.
https://kubernetes.io/ko/docs/concepts/scheduling-eviction/assign-pod-node/#%EC%96%B4%ED%94%BC%EB%8B%88%ED%8B%B0-affinity-%EC%99%80-%EC%95%88%ED%8B%B0-%EC%96%B4%ED%94%BC%EB%8B%88%ED%8B%B0-anti-affinity
노드에 파드 할당하기
특정한 노드(들) 집합에서만 동작하도록 파드를 제한할 수 있다. 이를 수행하는 방법에는 여러 가지가 있으며 권장되는 접근 방식은 모두 레이블 셀렉터를 사용하여 선택을 용이하게 한다. 보통
kubernetes.io
1.2.1.2.1. 선호도 지정 방식
1.2.1.2.1.1. 쿠버네티스에게 어떤 노드가 특정 파드를 선호한다고 알림
1.2.1.2.1.2. 쿠버네티스는 해당 노드 중 하나에 파드를 스케줄링하고자 시도
1.2.1.2.1.3. 해당 노드에 스케줄링이 불가능할 경우 다른 노드를 선택해 스케줄링
1.3. 디폴트 노드 테이블 검사
1.3.1. 노드 어피니티는 노드 레이블을 기반으로 노드를 선택
1.3.2. 핵심 디폴트 레이블
1.3.2.1. failure-domain.beta.kubernetes.io/region [노드 위치 지리적 리전 지정]
1.3.2.2. failure-domain.beta.kubernetes.io/zone [노드 가용영역 지정]
1.3.2.3. kubernetes.io/hostname [노드의 호스트 이름]
2. 하드 노드 어피니티 규칙 지정
2.1. 노드 셀렉터를 사용하는 파드 - 해당 레이블 포함 노드에만 배포하도록 지정
$ cat kubia-gpu-nodeselector.yaml
apiVersion: v1
kind: Pod
metadata:
name: kubia-gpu
spec:
nodeSelector:
gpu: "true"
containers:
- image: luksa/kubia
name: kubia
2.2. 노드 어피니티를 사용하는 파드
$ cat kubia-gpu-nodeaffinity.yaml
apiVersion: v1
kind: Pod
metadata:
name: kubia-gpu
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: gpu
operator: In
values:
- "true"
containers:
- image: luksa/kubia
name: kubia
2.2.1. 노드 어피니티 개별 속성 이해
2.2.1.1. requiredDuringSchedulingIgnoredDuringExecution
2.2.1.1.1. requiredDuringScheduling : 해당 필드 아래 정의된 규칙은, 파드가 노드로 스케줄링되고자 가져야 하는 레이블을 지정
2.2.1.1.2. IgnoredDuringExecution : 해당 필드 아래 정의된 규칙은, 노드에서 이미 실행 중인 파드에는 영향 없음
2.2.1.2. nodeSelectorTerms 이해
2.2.1.2.1. nodeSelectorTerms: - matchExpressions ) 파드를 노드에 스케줄링하고자 노드 레이블이 일치하도록 표현식 정의
3. 파드 스케줄링 시점의 노드 우선순위 지정
3.1. preferredDuringSchedulingIgnoredDuringExecution
3.1.1. 설명 : 특정 파드를 스케줄링할 때 스케줄러가 선호할 노드를 지정
3.1.2. 사용예시 : 특정 가용영역 및 머신에 스케줄링되는 것을 우선적으로 선호하는 경우
3.2. 노드 레이블링 : 노드에 적절한 레이블 지정
3.2.1. 각 노드에 노드가 속한 가용영역 지정 레이블을 지정
3.2.2. 각 노드에 전용/공유 노드로 표시하는 레이블을 지정
3.2.2.1. 전용/공유 노드 표시 : share-type=dedicated OR share-type=shared
3.3. 선호 노드 어피니티 규칙 지정
3.3.1. 선호 노드 어피니티 규칙 지정 사례
3.3.1.1. availability-zone=zone1, share-type=dedicated 레이블 포함 파드 스케줄링
3.3.1.2. 선호도에 따른 가중치 설정
$ cat preferred-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: pref
spec:
replicas: 5
selector:
matchLabels:
app: pref
template:
metadata:
labels:
app: pref
spec:
affinity:
nodeAffinity:
// 필수 요구사항이 아닌 선호도의 명시
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 80
preference:
matchExpressions:
- key: availability-zone
operator: In
values:
- zone1
- weight: 20
preference:
matchExpressions:
- key: share-type
operator: In
values:
- dedicated
containers:
- args:
- sleep
- "99999"
image: busybox
name: main
3.3.2. 노드 선호도 작동 방법 이해
3.3.2.1. 예시의 경우에는, 가중치에 따라 해당 조건을 모두 만족한 경우 > 가중치가 더 높은 조건만 만족한 경우 > 가중치가 더 낮은 조건만 만족한 경우 > 모두 만족하지 않은 경우로 4가지 그룹으로 노드를 분류하여 우선순위가 높은 순서대로 스케줄링한다.
파드 어피니티와 안티 어피니티 이용해 파드 함께 배치하기
1. 파드를 함께 배치하는 일의 필요성
1.1. 프론트엔드 파드와 백엔드 파드를 가까이 배치해 대기 시간 감소 및 애플리케이션 성능 향상 기대
2. 어피니티를 사용해 같은 노드에 파드 배포
$ k run backend -l app=backend --image busybox -- sleep 999992.1. 앞서 추가한 백엔드 파드의 레이블을 활용해 프론트엔드 파드 내 [파드 어피니티] 설정에 추가하여, 해당 디플로이먼트의 파드는 셀렉터와 일치하는 노드에 배포 (해당 레이블을 지난 파드와 같은 노드에 배치하도록 배포)
$ cat frontend-podaffinity-host.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: frontend
spec:
replicas: 5
template:
metadata:
labels:
app: frontend
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- topologyKey: kubernetes.io/hostname
labelSelector:
matchLabels:
app: backend
containers:
- name: main
image: busybox
args:
- sleep
- "99999"2.2. 스케줄러의 파드 어피니티 규칙 활용 방식
2.2.1. 어피니티 규칙을 정의하지 않은 백엔드 파드를 삭제하는 경우 (app=backend 레이블 보유)
2.2.2. 스케줄러가 프론트엔드 파드의 파드 어피니티 설정에 정의된 레이블셀렉터를 기반으로 레이블 일치 파드 모두 확인
2.2.3. 스케줄러가 해당 파드들을 다시 동일한 위치에 (프론트엔드 파드가 존재하는 동일 노드) 배포
2.2.3.1. 스케줄러의 해당 배포 방식은, 기존 프론트엔드 파드의 파드 어피니티 규칙성 유지를 위함
2.2.3.2. 파드 어피니티로 인해 기존에 프론트엔드 파드가 존재하는 노드가 보다 높은 우선순위 점수를 확보
3. 동일 랙, 가용영역 혹은 동일 리전에 배포
3.1. topologyKey 속성의 작동 방법
3.1.1. 개요 : 파드 어피니티 내 topologyKey 속성이 파드의 스케줄 범위를 결정.
3.1.2. 상세
3.1.2.1. 각 노드에 해당 topologyKey 속성에 맞게 레이블을 지정 (topologyKey 값이 rack이라면, rack=rack1과 같은 레이블을 노드 일부에 부여하고 나머지는 rack=rack2 레이블을 부여)
3.1.2.2. 파드 어피니티 정의 시 topologyKey 속성을 failure-domain.beta.kubernetes.io/rack 값으로 설정
3.1.2.3. 스케줄러가 스케줄링 과정에서 파드 어피니티 구성을 확인해 조건에 일치하는 파드, 노드를 찾음
3.1.2.3.1. 확인 조건 1 : 레이블 셀렉터와 일치하는 파드와 그 파드가 실행 중인 노드를 찾음 (단, 레이블 셀렉터는 동일 네임스페이스 내 파드만 일치 확인을 진행하므로, 레이블 셀렉터와 동일 레벨에 네임스페이스 필드를 추가해야 다른 네임스페이스 내 파드도 확인 가능)
3.1.2.3.2. 확인 조건 2 : 파드 어피니티 지정 topologyKey 필드와 일치하는 키를 가진 노드 레이블을 지닌 노드를 찾음
3.1.2.4. 앞서 찾은 노드 중 하나를 선택해 파드를 스케줄링함.
3.2. 동일 가용영역에 파드 배포
3.2.1. topologyKey 속성을 failure-domain.beta.kubernetes.io/zone 값으로 변경
3.3. 동일 리전에 파드 배포
3.3.1. topologyKey 속성을 failure-domain.beta.kubernetes.io/region 값으로 변경
3.4. 동일 랙에 파드 배포
3.4.1. topologyKey 속성을 failure-domain.beta.kubernetes.io/rack 값으로 변경
3.5. 필수 요구사항이 아닌 파드 어피니티 선호도 표시
$ cat frontend-podaffinity-preferred-host.yaml
...
spec:
replicas: 5
template: ...
spec:
affinity:
podAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 80
podAffinityTerm:
topologyKey: kubernetes.io/hostname
labelSelector:
matchLabels:
app: backend
containers: ...
3.6. 파드 안티 어피니티를 사용해 파드들이 서로 멀어지게 스케줄링
3.6.1. 스케줄러는 파드안티어피니티 레이블 셀렉터와 일치하는 파드가 실행 중인 노드를 선택하지 않음
3.6.2. 파드 어피니티와 마찬가지로 preferredDuringSchedulingIgnoredDuringExecution과 가중치를 통해 소프트 요구사항, 선호도 형태로도 스케줄링을 조정할 수 있음. 다만 우려 사항이 있는 시나리오의 경우 되도록 필수 요구사항으로 미리 사고를 방지할 것을 권고.
$ cat frontend-podantiaffinity-host.yaml
...
spec:
replicas: 5
template: ...
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- topologyKey: kubernetes.io/hostname
labelSelector:
matchLabels:
app: frontend
containers: ...
Quote From Senior
고급 스케줄링은, 온프레미스 IDC 상에서 큰 쿠버네티스 팜을 운영하는 기업들에게 보다 적합한 기능이라 할 수 있다. 수많은 워커노드들을 운영하면서 각기 다른 요구사항을 반영한 배포를 구현하기 위해 필요한 기능이다.
그에 반해 서비스 당 하나의 클러스터를 운영하는 중소규모의 운영팀의 경우에는 고급 스케줄링 기능까지는 필요 없이 노드 셀렉터, 노드 어피니티 수준에서 그 배포를 관리하는 것만으로도 충분하다. 주 운영 서비스와 보조 서비스가 있다고 할 때, 보조 서비스를 면밀히 노드그룹을 분리해 스케줄링을 세부 조정하기보다, 하나의 별도 클러스터로 격리시키는 것이 효율적인 의사 결정이다.
모든 기능을 활용해 모든 요구사항을 반영하기 보다, 요구사항을 단순화해서 간단한 아키텍처를 가지고 가도록 중재하고 설계하는 것이 중요한 역량이다. YAGNI 원칙을 떠올리자.
YAGNI(You aren't gonna need it)는 프로그래머가 필요하다고 간주할 때까지 기능을 추가하지 않는 것이 좋다는 익스트림 프로그래밍(XP)의 원칙이다. 익스트림 프로그래밍의 공동 설립자 론 제프리스는 다음과 같이 썼다: "실제로 필요할 때 무조건 구현하되, 그저 필요할 것이라고 예상할 때에는 절대 구현하지 말라." "You aren't going to need it"와 "You ain't gonna need it"의 준말로도 인용된다.
https://ko.wikipedia.org/wiki/YAGNI
'기술 공부 > 쿠버네티스' 카테고리의 다른 글
| 쿠버네티스 (18) | CRD, 서비스 카탈로그, 오픈시프트, Helm (0) | 2022.04.14 |
|---|---|
| 쿠버네티스 (17) | 모범 사례 탐구 (0) | 2022.03.31 |
| 쿠버네티스 (15) | 오토스케일링 (0) | 2022.03.31 |
| 쿠버네티스 (14) | 파드 컴퓨팅 리소스 (0) | 2022.03.23 |
| 쿠버네티스 (13) | 클러스터 노드와 네트워크 보안 (0) | 2022.03.23 |