TreeviewCopyright © Pengfei Ni all right reserved, powered by aleen42

Kubernetes 201

어플리케이션 확장

Depolyment에서 복제본 수를 수정하면 어플리케이션을 동적으로 확장하거나 축소할 수 있습니다.

scale

이러한 자동 확장된 컨테이너는 자동으로 서비스에 추가되고, 축소된 컨테이너는 자동으로 서비스에서 삭제됩니다:

$ kubectl scale --replicas=3 deployment/nginx-app
$ kubectl get deploy
NAME        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-app   3         3         3            3           10m

롤링 업데이트

롤링 업데이트는 컨테이너를 점진적으로 교체하여 무중단으로 서비스를 업그레이드할 수 있게 합니다:

kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2

update1

update2

update3

update4

롤링 업데이트 과정에서 오류가 발생하거나 설정 오류가 발견되면 언제든지 롤백할 수 있습니다:

kubectl rolling-update frontend-v1 frontend-v2 --rollback

주의해야할 것은 kubectl rolling-update는 ReplicationController에 대해서만 다룬다는 것입니다. (Deployment는 스펙에 따라 업데이트 전략을 세우는 것을 전제로 하며, 암묵적으로 설정되는 것이 바로 RollingUpdate 입니다.) 다음과 같이 어플리케이션을 업데이트하면 롤링 업데이트합니다:

  spec:
    replicas: 3
    selector:
      matchLabels:
        run: nginx-app
    strategy:
      rollingUpdate:
        maxSurge: 1
        maxUnavailable: 1
      type: RollingUpdate

어플리케이션을 업데이트할 때, kubectl set 명령을 사용할 수 있습니다:

kubectl set image deployment/nginx-app nginx-app=nginx:1.9.1

롤링 업데이트 하는 과정은 rollout라는 명령으로 볼 수 있습니다:

$ kubectl rollout status deployment/nginx-app
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for rollout to finish: 2 of 3 updated replicas are available...
Waiting for rollout to finish: 2 of 3 updated replicas are available...
Waiting for rollout to finish: 2 of 3 updated replicas are available...
Waiting for rollout to finish: 2 of 3 updated replicas are available...
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx-app" successfully rolled out

Deployment는 롤백도 지원합니다:

$ kubectl rollout history deployment/nginx-app
deployments "nginx-app"
REVISION    CHANGE-CAUSE
1        <none>
2        <none>

$ kubectl rollout undo deployment/nginx-app
deployment "nginx-app" rolled back

자원 제한

Kubernetes는 컨테이너를 통해 컨테이너 자원 관리의 기능을 제공하고 있습니다. 예를 들어, 컨테이너의 CPU와 메모리 사용을 제한할 수 있으며, 방금 전에 만든 Deployment에 대해서 아래의 명령으로 최대 50%의 CPU와 128MB의 메모리로 제한할 수 있습니다:

$ kubectl set resources deployment nginx-app -c=nginx --limits=cpu=500m,memory=128Mi
deployment "nginx" resource requirements updated

이는 각 팟마다 자원 제한을 설정하는 것과 같습니다:

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

상태 확인

Kubernetes는 어플리케이션 지향 클리스터 관리 도구로써, 컨테이너가 있어야 정상적인 운영 상태를 확보할 수 있습니다. Kubernetes는 컨테이너의 상태를 조사하기 위해 두 가지 프로브(Probe, exec, tcpSocket 및 http 메소드 지원)를 제공합니다.

  • LivenessProbe: 앱이 정상인지 여부를 감지하고, 정상이 아닌 경우 컨테이너를 삭제하고 다시 만듭니다.
  • ReadinessProbe: 앱이 시작되고 정상 서비스 상태인지 그리고 Kubernetes 서비스에서 트래픽을 수신하지 않는지를 감지합니다.

Deployment가 배포되면, kubectl edit deployment/nginx-app로 매니페스트를 업데이트하여 상태 확인 섹션을 추가할 수 있습니다:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: http
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        resources:
          limits:
            cpu: "500m"
            memory: "128Mi"
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 15
          timeoutSeconds: 1
        readinessProbe:
          httpGet:
            path: /ping
            port: 80
          initialDelaySeconds: 5
          timeoutSeconds: 1

results matching ""

    No results matching ""