11. 쿠버네티스 실전편(잡, 크론잡, 시크릿)

2019-06-02

kubernetes

파드, 레플리카세트, 디플로이먼트, 서비스, 인그레스는 데몬으로 동작하는 서버 어플리케이션을 구축할 때 사용되는 기본 리소스이다
쿠버네티스는 데몬으로 동작하는 서버 어플리케이션 외에도 배치 서버등 다양한 형태의 어플리케이션을 구축할 수 있다.

잡

잡은 하나 이상의 파드를 생성해 지정된 수의 파드가 정상 종료될 때까지 이를 관리하는 리소스다.
잡이 생성한 파드는 정상 종료된 후에도 삭제되지 않고 그대로 남아있기 때문에 작업이 종료된 후에 파드의 로그나 실행 결과를 분석할 수 있다. 그러므로 배치작업 위추의 어플리케이션에 적합하다.
잡은 파드 여러개를 병렬로 실행하는 방법으로 쉽게 스케일 아웃이 가능하다.

apiVersion: batch/v1
kind: Job
metadata:
  name: pingpong
  labels:
    app: pingpong
spec:
  parallelism: 3    # 동시에 실행하는 파드의 수를 지정하는 속성. 파드를 병렬로 실행해야할 때 편리
  template:
    metadata:
      labels:
        app: pingpong
    spec:
      containers:
      - name: pingpong
        image: gihyodocker/alpine:bash
        command: ["/bin/sh"]
        args:
          - "-c"
          - |
            echo [`date`] ping!
            sleep 10
            echo [`date`] pong!
      restartPolicy: Never

위의 코드를 yaml파일로 만들고 아래 명령어를 통해 확인해보자.

1 2	$ kubectl apply -f test.yaml $ kubectl get pod -l app=pingpong --show-all

parallelism와 replicas의 차이점은 무엇일까?
replicas가 3이면 동일한 파드를 3개 만들라는 것이고, parallelism이 이면 동시에 3개의 파드를 실행하는것인데… 확인해보니 parallelism도 파드를 3개 만들긴함.

잡 리소스는 restartPolicy 속성을 Never, OnFailure중 하나를 설정해야 한다.

크론잡

잡 리소스는 파드가 단 한번만 실행되는데 반해 크론잡 리소스는 스케줄을 지정해 정기적으로 파드를 실행할 수 있다. 즉 정기적으로 파드를 실행할 수 있다.

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: pingpong
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        metadata:
          labels:
            app: pingpong
        spec:
          containers:
          - name: pingpong
            image: gihyodocker/alpine:bash
            command: ["/bin/sh"]
            args:
              - "-c"
              - |
                echo [`date`] ping!
                sleep 10
                echo [`date`] pong!
          restartPolicy: OnFailure

spec.schedule속성에 Cron과 같은 포맷으로 파드를 실행할 스케줄을 정의한다. 또한 spec.jobTemplate 아래에 잡 리소스와 마찬가지로 파드 정의가 들어가면 된다.
보통의 경우 리눅스 crontab으로 스케줄에 맞춰 스크립트를 실행하는게 대부분이었따. 하지만 크론잡 리소스를 이용하면 이 모든것을 컨테이너로 해결할 수 있다.

시크릿

쿠버네티스의 시크릿 리소스를 사용하면 기밀정보 문자열을 Base 인코딩으로 만들 수 있다.

apiVersion: v1
kind: Secret
metadata:
  name: nginx-secret
type: Opaque
data:
  .htpasswd: eW91cl91c2VybmFtZTpyejc5SXpTalplaWZvCg==

위 코드를 활용해 아래에 적용가능하다.

apiVersion: v1
kind: Service
metadata:
  name: basic-auth
spec:
  type: NodePort
  selector:
    app: basic-auth
  ports:
  - protocol: TCP
    port: 80
    targetPort: http
    nodePort: 30060

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: basic-auth
  labels:
    app: basic-auth
spec:
  replicas: 1
  selector:
    matchLabels:
      app: basic-auth
  template:
    metadata:
      labels:
        app: basic-auth
    spec:
      containers:
      - name: nginx
        image: "gihyodocker/nginx:latest"
        imagePullPolicy: Always
        ports:
          - name: http
            containerPort: 80
        env:
          - name: BACKEND_HOST
            value: "localhost:8080"
          - name: BASIC_AUTH_FILE
            value: "/etc/nginx/secret/.htpasswd"    
        volumeMounts:
          - mountPath: /etc/nginx/secret    # 이 경로에 .htpasswd가 생성된다.
            name: nginx-secret
            readOnly: true
      - name: echo
        image: "gihyodocker/echo:latest"
        imagePullPolicy: Always
        ports:
          - containerPort: 8080
        env:
          - name: HTTP_PORT
            value: "8080"
      volumes:
      - name: nginx-secret
        secret:
          secretName: nginx-secret

인증정보를 환경 변수로 관리하는 기법또한 존재한다. 이는 259p를 참고하자.

CSMSA

잡

크론잡

시크릿