쿠베르네트스는 통속적이고 알기 쉬운 영어로 이야기를 했다

쿠버네트스에서, 기중기는 가장 작은 배치 가능한 작업 부하 단원이다.그래서 뻔한 문제는 다음과 같다.

"Where should the pods be deployed?"

Pods always execute inside a Node.

But but.. there are so many Nodes - which one should node should I deploy this pod to ??!

Hello - "Kubernetes Scheduler"

Kubernetes 스케줄러가 어떻게 작동하는지, 그리고 간단한 영어로 노드를 선택하는 방식을 클래스별로 분석해 봅시다.
만약에 우리가'사교 식당'을 하나 가지고 있다면 거기에 우리는 몇 개의 테이블과 각 테이블 주위의 몇 개의 좌석이 있고 많은 고객과 호텔 종업원이 있다.'사교 식당'은 좌석이 충분하고 모든 조건이 충족되면 서로 다른 고객이 같은 테이블 옆에 둘러앉을 수 있다는 뜻이다.

표 = 노드(VM 또는 물리적 시스템)
자리 = 가상 시스템의 리소스 가용성
종업원 = 쿠버 스케줄러
고객 기반 = Pod
그룹 내 단일 고객 = 컨테이너

1. 리소스 요구사항 및 가용성

한 **고객군*식당에 들어가서 간단하게 테이블 하나를 앉으라고 요구한다.종업원은 고객층의 수요를 분석하고 좌석이 얼마나 필요한지 확인한다.그리고 그는 사용할 수 있는 모든 탁자를 살펴보고'배치'가 불가능한 탁자를 선별하여 좌석 요구를 충족시킬 수 있는 탁자를 분배(귀속)했다.*
이것은 기본적인 스케줄링 방식입니다. kube 스케줄러가 API 서버를 계속 감시하여 스케줄링되지 않은 POD가 있는지 확인합니다.POD의 각 컨테이너에 대한 리소스 요구사항을 봅니다.

Remember the containers are the ones which have the resource requirement in the spec not the pods themselves.

다음 예에서pod배치된 용기 규범에 따라 CPU와 메모리 수요가 있습니다.500밀리 CPU 및 128 MiB 메모리가 필요합니다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    resources:
      requests:
        memory: "128Mi"
        cpu: "500m"

이제 충분한 용량을 확보하기 위해 그 중 하나 (식당 테이블) 를 살펴보자.Dell의 접근 방식은 다음 명령을 실행하는 것입니다.

kubectl describe nodes <node-name>

그것은 노드의 모든 속성을 출력하지만, 우리가 흥미를 느끼는 것은 용량과 분배성이다.
CPU와 메모리는 유일한 선별 기준이 아니라 지구성 저장소, 네트워크 포트와 같은 요구 사항도 많다는 것을 명심하십시오.여기에 상세한 명세서가 있다.

2. 노드 선택기

또 다른 **고객층*은 식당에 와서 그 어떤'파란색'탁자 위에 놓아 달라고 요구했다.종업원은 그의 재고를 살펴보고 모든 라벨이 파란색인 탁자를 찾아 고객군을 상응하는 탁자에 배치한다*
이 경우,pod는 노드 선택기 (키 값 쌍) 를 지정합니다. 이 선택기는pod를 키 값과 일치하는 모든 노드에 배치할 것을 요청합니다.
다음은 새 YAML 파일의 모양입니다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-blue
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
  nodeSelector:
    color: blue

모든 my 노드를 조회해서 탭이 '파란색' 인지 확인하기 위해서 다음 명령을 실행합니다.

kubectl get nodes --show-labels

목록에서'worker-2'의 라벨이color=blue인 것을 볼 수 있습니다.Kubernetes도 내장 탭을 제공합니다.

위대하다만약 지금 그것을 배치한다면, 스케줄러는 자동으로 그것을 정확한 노드에 분배할 것이다.(일꾼2).우리는 아래 명령을 실행해서 이 점을 확인할 수 있다.

kubectl get pod -o wide

Note that if you did not have a node with the appropriate label the deployment would be Pending.

3. 노드 친화력과 반친화력

노드 친화력과 반친화력은 노드 선택기와 매우 유사하지만 표현적 언어와 소프트/하드 선호를 지원하여 하드 수요가 아니라 더욱 큰 유연성을 제공합니다.

다른 **고객군이 식당에 온다고 가정해 보세요.그들은 어떤 해경의 책상 위에 놓는 것을 좋아하지만, 반드시 필요한 것은 아니다.종업원은 그의 재고를 살펴보고 "ocean"라벨이 표시된 모든 탁자를 찾아 고객군을 상응하는 탁자에 분배한다*
이 예에서pod는 nodeAffinity를 정의하여 키 값이 -->view:ocean과 일치하는'노드'를 더 좋아한다는 것을 나타낸다. (우리는 아래의 일치 표현식을 통해 실현한다)
여기에는 두 가지 옵션이 있습니다.

preferredDuringSchedulingIgnoredDuringExecution: 조건에 맞는 노드를 우선적으로 선택하지만 노드에 분배될 때에는 보장되지 않습니다.

IgnoredduringExecution - pod를 스케줄링한 후 노드의 탭을 삭제하거나 변경하면pod가 삭제되지 않습니다.다시 말하면, 관련 선택은 스케줄링pod에서만 유효하지만, 실행할 때에는 무효이다

requiredDuringSchedulingIgnoredDuringExecution: 노드를 선택할 때 조건에 맞는 노드가 필요하다는 것을 의미합니다.IgnoreDuringExecution은 이전과 같습니다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-oceanview
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
            - key: view
              operator: In
              values:
                - ocean

The operator in this case can also be other values such as In, NotIn, Exists, DoesNotExist, Gt, Lt. NotIn and DoesNotExist will create the opposite effect of nodeAntiAffinity

4. Pod 친화력과 반친화력

또 다른 채식 소녀 길드 * 고객군 * 식당에 왔습니다.그들은 이미 육식자가 앉은 탁자 위에 놓아서는 안 된다는 요구가 있었다.그들은 약간 까다롭다. 그들은 아직도 남자아이가 앉은 책상 위에 앉고 싶어 한다.다시 말하면 그들은 육식자에게는 친화력이 없지만 남자아이에게는 친화력이 있다*
실제 장면을 예로 들겠습니다. 이 장면에서 리디스 캐시와 웹 서버 배치가 있습니다.조건은 다음과 같습니다.

redis 캐시 크레인을 웹 서버 크레인에 최대한 가까운 위치(podAffinity)

에 배치하기를 원합니다.

같은 노드에 두 개의 리디스 캐시 크레인(podAntiaffinity)이 있는 것을 원하지 않습니다

같은 노드(PodAntiaffinity)에 두 개의 웹 서버 크레인을 설치하고 싶지 않습니다

이러한 규칙이 노드의 범위에 적용되기를 원합니다.(토폴로지학)

다음은 Redis 캐시 배치 YAML의 모양입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-cache
spec:
  selector:
    matchLabels:
      apptype: redis-cache
  replicas: 3
  template:
    metadata:
      labels:
        apptype: redis-cache
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: apptype
                operator: In
                values:
                - redis-cache
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: redis-server
        image: redis:3.2-alpine

위의 예에서는 다음과 같이 설명합니다.

위의 예시에서 리디스 캐시 탭(apptype=redis cache)이 각각 배치

의 일부분으로pod에 추가된 것을 볼 수 있습니다.

podAntiAffinity에 대한 설명은 같은 서버에 두 개의 Redis 캐시 Pod가 설치되어 있지 않다는 것이다.이것은 내장 토폴로지'kubernetes.io/hostname'에 의해 정의된 것으로 단일 노드임을 의미합니다.필요하면, 지역이나 다른 합법적인 키로도 확장할 수 있습니다.

대단합니다. 그것을 배치하면 다음과 같은 결과를 얻을 수 있습니다.

이제 웹 서버 배치 YAML 파일을 살펴보겠습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  selector:
    matchLabels:
      apptype: web-server
  replicas: 3
  template:
    metadata:
      labels:
        apptype: web-server
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: apptype
                operator: In
                values:
                - web-server
            topologyKey: "kubernetes.io/hostname"
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: apptype
                operator: In
                values:
                - redis-cache
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: web-app
        image: nginx:1.12-alpine

위의 예에서는 다음과 같이 설명합니다.

위의 예시에서 웹 서버 탭(apptype=웹 서버)이 각각 배치

의 일부분으로pod에 추가된 것을 볼 수 있습니다.

podAntiAffinity에 대한 설명은 같은 서버에 두 개의 웹 서버Pod가 설치되어 있지 않다는 것이다.이것은 내장 토폴로지'kubernetes.io/hostname'에 의해 정의된 것으로 단일 노드임을 의미합니다.필요하면, 지역이나 다른 합법적인 키로도 확장할 수 있습니다.

podAffinity에 대한 설명으로 웹 서버 Pod는 가능한 한 Redis 캐시 배치에 접근할 수 있습니다.

일단 당신이 그것을 배치하면 우리는 우리의 목표인 웹 서버 3대와 Redis 캐시 서버 3대를 달성할 수 있습니다. 서버마다 하나의 노드에 복사본이 있습니다.

5. 오점과 용인

이번에는 식당 테이블 하나가 땅콩 유출 사고로 오염됐다.그래서 알레르기 반응을 피하기 위해 이 테이블에 새로운 ** 고객군을 배치하지 않겠다고 합니다.따라서 이 오염된 표를 제외한 모든 새로운 고객팀은 다른 표에 놓여 있습니다.*
지금까지 우리는pod의 관점에서 스케줄을 연구해 왔다.그러나 노드의 다른 측면에서 새로운pod를 배치하지 않기로 결정한다면?이것이 바로 오점의 근원이다.일단 노드 하나를 오염시키면 두 가지 선택이 있다.

NoSchedule - 이것은pod가 오염되면 이pod에 새로운pod를 배치하지 말아야 한다는 것을 의미합니다 *그들이 용인할 수 없다면

NoExecute - 기존의 크레인이 오염되면 크레인에서 쫓겨납니다*그들이 용인하지 않는 한

그러면 우리는 어떻게 한 노드를 오염시킵니까?

kubectl taint nodes <nodename> mytaintkey=mytaintvalue:NoSchedule

이 집합을 설정하면 노드가 다음 키 값에 의해 오염됩니다. (mytaintkey=mytaintvalue)그래서 새로운 기중기를 배치할 수 없다.
그러나 노드에서 기존pod를 제거하려면 어떻게 해야 합니까?

kubectl taint nodes <nodename> mytaintkey=mytaintvalue:NoExecute

이렇게 하면 현재 노드에서 모든 POD가 제거되고 사용 가능한 다른 노드로 이동합니다.

그러나 잠시 후 한 고객 단체가 와서 "오, 괜찮아요. 땅콩 알레르기가 있어요.*'내수성'**그러니까 계속 오염된 책상 위에 놓으세요."라고 말했다.Kube 스케줄러는 허용도를 확인하고 오염된 테이블에 넣습니다*
현재pod가 노드에서 지정한 오점 키 값에 대해 용인도가 있다면 이pod는 오점의 영향을 받지 않고 필요할 때 노드에 놓입니다.

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  containers:
  - name: web-app
    image: nginx:1.12-alpine
  tolerations:
  - key: "mytaintkey"
    operator: "Equal"
    value: "mytaintvalue"
    effect: "NoExecute"

이것은 카슨 앤더슨 (Carson Anderson) 이 그의
본문은 최초로 발표되었다www.azuremonk.com