네이티브 쿠버네티스

네이티브 쿠버네티스 (Native Kubernetes)

이 페이지에서는 Flink를 [Kubernetes] 위에 네이티브하게 배포하는 방법을 설명합니다. 네이티브 쿠버네티스 통합을 통해 실행 중인 쿠버네티스 클러스터에 Flink를 직접 배포할 수 있으며, Flink가 쿠버네티스와 직접 통신하므로 필요한 리소스에 따라 TaskManager를 동적으로 할당하거나 해제할 수 있습니다. 생산 환경에서는 애플리케이션 모드(Application Mode)로 배포하는 것을 권장합니다.

출처: 문서

본문

Getting Started (시작하기)

이 Getting Started 섹션에서는 쿠버네티스에서 완전히 동작하는 Flink 클러스터를 구축하는 방법을 안내합니다.

Introduction (소개)

Kubernetes는 컴퓨터 애플리케이션 배포, 확장, 관리를 자동화하는 대표적인 컨테이너 오케스트레이션 시스템입니다. Flink의 네이티브 쿠버네티스 통합은 실행 중인 쿠버네티스 클러스터에 Flink를 직접 배포할 수 있게 해줍니다. 또한 Flink는 쿠버네티스와 직접 통신할 수 있기 때문에 필요한 리소스에 따라 TaskManager를 동적으로 할당하고 해제할 수 있습니다.

Apache Flink는 쿠버네티스에서 Flink 클러스터를 관리하기 위한 Kubernetes operator도 제공합니다. 이 operator는 standalone 및 native 배포 모드를 모두 지원하며, 쿠버네티스에서 Flink 리소스의 배포, 구성, 생명주기 관리를 크게 단순화합니다.

자세한 내용은 [Flink Kubernetes Operator documentation]을 참조하세요.

Preparation (준비 사항)

Getting Started 섹션은 다음 요구 사항을 충족하는 실행 중인 쿠버네티스 클러스터를 가정합니다:

• Kubernetes >= 1.9.
• ~/.kube/config를 통해 설정할 수 있으며 pod 및 service를 list, create, delete할 권한이 있는 KubeConfig. kubectl auth can-i <list|create|edit|delete> pods를 실행하여 권한을 확인할 수 있습니다.
• 활성화된 Kubernetes DNS.
• pod를 생성·삭제할 수 있는 [RBAC] 권한을 가진 default service account.

쿠버네티스 클러스터 설정에 문제가 있다면 [how to setup a Kubernetes cluster]를 참조하세요.

Starting a Flink Session on Kubernetes

쿠버네티스 클러스터가 실행 중이고 kubectl이 그 클러스터를 가리키도록 설정되었다면, [Session Mode]로 Flink 클러스터를 다음과 같이 실행할 수 있습니다:

# (1) Start Kubernetes session
$ ./bin/kubernetes-session.sh -Dkubernetes.cluster-id=my-first-flink-cluster

# (2) Submit example job
$ ./bin/flink run \
    --target kubernetes-session \
    -Dkubernetes.cluster-id=my-first-flink-cluster \
    ./examples/streaming/TopSpeedWindowing.jar

# (3) Stop Kubernetes session by deleting cluster deployment
$ kubectl delete deployment/my-first-flink-cluster

기본적으로 Flink의 Web UI와 REST 엔드포인트는 ClusterIP service로 노출됩니다. 서비스에 접근하려면 [Accessing Flink's Web UI]의 지침을 참조하세요.

축하합니다! 쿠버네티스에 Flink를 배포하여 Flink 애플리케이션을 성공적으로 실행했습니다.

Deployment Modes (배포 모드)

생산 환경에서는 Flink 애플리케이션을 [Application Mode]로 배포할 것을 권장합니다. 이 모드는 애플리케이션에 더 나은 격리를 제공합니다.

Application Mode (애플리케이션 모드)

애플리케이션 모드의 전반적인 개념은 [deployment mode overview]를 참조하세요.

[Application Mode]는 사용자 코드를 클러스터에서 실행하므로 사용자 코드가 Flink 이미지와 함께 번들되어 있어야 합니다. Application Mode는 애플리케이션 종료 후 모든 Flink 컴포넌트가 제대로 정리되도록 보장합니다. 번들은 기본 Flink Docker 이미지를 수정하거나, 로컬에 없는 아티팩트를 업로드·다운로드할 수 있게 해주는 User Artifact Management를 통해 수행할 수 있습니다.

Modify the Docker image

Flink 커뮤니티는 사용자 코드를 번들하는 데 사용할 수 있는 [base Docker image]를 제공합니다:

FROM flink
RUN mkdir -p $FLINK_HOME/usrlib
COPY /path/of/my-flink-job.jar $FLINK_HOME/usrlib/my-flink-job.jar

custom-image-name 이름으로 Docker 이미지를 만들고 게시한 후 다음과 같이 Application 클러스터를 시작할 수 있습니다:

$ ./bin/flink run \
    --target kubernetes-application \
    -Dkubernetes.cluster-id=my-first-application-cluster \
    -Dkubernetes.container.image.ref=custom-image-name \
    local:///opt/flink/usrlib/my-flink-job.jar

Configure User Artifact Management

로컬에 Flink job JAR가 있다면 아티팩트 업로드를 사용하여 배포 중에 로컬 아티팩트를 DFS에 업로드하고, 배포된 JobManager pod에서 가져오도록 할 수 있습니다:

$ ./bin/flink run \
    --target kubernetes-application \
    -Dkubernetes.cluster-id=my-first-application-cluster \
    -Dkubernetes.container.image=custom-image-name \
    -Dkubernetes.artifacts.local-upload-enabled=true \
    -Dkubernetes.artifacts.local-upload-target=s3://my-bucket/ \
    local:///tmp/my-flink-job.jar

kubernetes.artifacts.local-upload-enabled가 이 기능을 활성화하며, kubernetes.artifacts.local-upload-target은 존재하고 권한이 제대로 설정된 유효한 원격 대상을 가리켜야 합니다. user.artifacts.artifact-list 구성 옵션을 통해 로컬 및 원격 아티팩트를 혼합하여 추가할 수 있습니다:

$ ./bin/flink run \
    --target kubernetes-application \
    -Dkubernetes.cluster-id=my-first-application-cluster \
    -Dkubernetes.container.image=custom-image-name \
    -Dkubernetes.artifacts.local-upload-enabled=true \
    -Dkubernetes.artifacts.local-upload-target=s3://my-bucket/ \
    -Duser.artifacts.artifact-list=local:///tmp/my-flink-udf1.jar\;s3://my-bucket/my-flink-udf2.jar \
    local:///tmp/my-flink-job.jar

job JAR나 추가 아티팩트가 이미 DFS 또는 HTTP(S)를 통해 원격에 존재한다면, Flink는 배포된 JobManager pod에서 단순히 가져옵니다:

# FileSystem
$ ./bin/flink run \
    --target kubernetes-application \
    -Dkubernetes.cluster-id=my-first-application-cluster \
    -Dkubernetes.container.image=custom-image-name \
    s3://my-bucket/my-flink-job.jar

# HTTP(S)
$ ./bin/flink run \
    --target kubernetes-application \
    -Dkubernetes.cluster-id=my-first-application-cluster \
    -Dkubernetes.container.image=custom-image-name \
    https://ip:port/my-flink-job.jar

로컬 업로드 중에는 이미 존재하는 아티팩트를 덮어쓰지 않는다는 점에 유의하세요!

JAR 가져오기는 Application Mode에서 [filesystems] 또는 HTTP(S) 다운로드를 지원합니다.

JAR는 이미지 내 [user.artifacts.base-dir]/[kubernetes.namespace]/[kubernetes.cluster-id] 경로로 다운로드됩니다.

kubernetes.cluster-id 옵션은 클러스터 이름을 지정하며 고유해야 합니다. 이 옵션을 지정하지 않으면 Flink가 임의의 이름을 생성합니다.

kubernetes.container.image.ref 옵션은 pod를 시작할 이미지를 지정합니다.

애플리케이션 클러스터가 배포되면 다음과 같이 상호작용할 수 있습니다:

# List running job on the cluster
$ ./bin/flink list --target kubernetes-application -Dkubernetes.cluster-id=my-first-application-cluster
# Cancel running job
$ ./bin/flink cancel --target kubernetes-application -Dkubernetes.cluster-id=my-first-application-cluster <jobId>

bin/flink에 -Dkey=value 형태의 키-값 쌍을 전달하여 [Flink configuration file]에 설정된 구성을 재정의할 수 있습니다.

Session Mode (세션 모드)

세션 모드의 전반적인 개념은 [deployment mode overview]를 참조하세요.

Session 클러스터의 배포는 이 페이지 상단의 [Getting Started] 가이드에서 확인했습니다.

Session Mode는 두 가지 모드로 실행할 수 있습니다:

• detached mode (기본값): kubernetes-session.sh가 쿠버네티스에 Flink 클러스터를 배포한 후 종료됩니다.

• attached mode (-Dexecution.attached=true): kubernetes-session.sh가 계속 실행되며, 실행 중인 Flink 클러스터를 제어하는 명령을 입력할 수 있습니다. 예를 들어 stop은 실행 중인 Session 클러스터를 중지합니다. help를 입력하면 지원되는 모든 명령을 볼 수 있습니다.

클러스터 id가 my-first-flink-cluster인 실행 중인 Session 클러스터에 다시 연결하려면 다음 명령을 사용합니다:

$ ./bin/kubernetes-session.sh \
    -Dkubernetes.cluster-id=my-first-flink-cluster \
    -Dexecution.attached=true

bin/kubernetes-session.sh에 -Dkey=value 키-값 쌍을 전달하여 [Flink configuration file]에 설정된 구성을 재정의할 수 있습니다.

Stop a Running Session Cluster

클러스터 id my-first-flink-cluster인 실행 중인 Session 클러스터를 중지하려면 [delete the Flink deployment]를 하거나 다음을 사용할 수 있습니다:

$ echo 'stop' | ./bin/kubernetes-session.sh \
    -Dkubernetes.cluster-id=my-first-flink-cluster \
    -Dexecution.attached=true

Flink on Kubernetes Reference

Configuring Flink on Kubernetes

쿠버네티스 전용 구성 옵션은 [configuration page]에 나열되어 있습니다.

Flink는 [Fabric8 Kubernetes client]를 사용하여 Kubernetes APIServer와 통신하며 Kubernetes 리소스(예: Deployment, Pod, ConfigMap, Service 등)를 생성/삭제하고 Pod와 ConfigMap을 감시합니다. 위의 Flink 구성 옵션 외에도 Fabric8 Kubernetes client의 일부 [expert options]은 시스템 속성이나 환경 변수를 통해 구성할 수 있습니다.

예를 들어 사용자는 다음 Flink 구성 옵션으로 동시 최대 요청 수를 설정할 수 있습니다:

containerized.master.env.KUBERNETES_MAX_CONCURRENT_REQUESTS: 200
env.java.opts.jobmanager: "-Dkubernetes.max.concurrent.requests=200"

Accessing Flink's Web UI

Flink의 Web UI와 REST 엔드포인트는 [kubernetes.rest-service.exposed.type] 구성 옵션을 통해 여러 방식으로 노출할 수 있습니다.

• ClusterIP: 서비스를 클러스터 내부 IP에 노출합니다. 서비스는 클러스터 내에서만 접근 가능합니다. JobManager UI에 접근하거나 기존 세션에 job을 제출하려면 로컬 프록시를 시작해야 합니다. 그런 다음 localhost:8081을 사용해 Flink job을 세션에 제출하거나 대시보드를 볼 수 있습니다.

$ kubectl port-forward service/<ServiceName> 8081

• NodePort: 각 노드의 IP에서 고정 포트(즉 NodePort)로 서비스를 노출합니다. <NodeIP>:<NodePort>를 사용해 JobManager 서비스에 접근할 수 있습니다.

• LoadBalancer: 클라우드 제공자의 로드 밸런서를 사용해 서비스를 외부로 노출합니다. 클라우드 제공자와 쿠버네티스가 로드 밸런서를 준비하는 데 시간이 걸리므로, 클라이언트 로그에 NodePort JobManager Web Interface가 나타날 수 있습니다. kubectl get services/<cluster-id>-rest로 EXTERNAL-IP를 얻어 http://<EXTERNAL-IP>:8081 형태의 로드 밸런서 JobManager Web Interface를 직접 구성할 수 있습니다.

쿠버네티스에서 [publishing services in Kubernetes]에 대한 공식 문서를 참조하세요.

환경에 따라 LoadBalancer REST service 노출 타입으로 Flink 클러스터를 시작하면 클러스터가 공개적으로 접근 가능해질 수 있습니다(보통 임의 코드를 실행할 수 있는 권한을 갖게 됩니다).

Logging

쿠버네티스 통합은 conf/log4j-console.properties와 conf/logback-console.xml을 ConfigMap으로 pod에 노출합니다. 이 파일들의 변경 사항은 새로 시작된 클러스터에 반영됩니다.

Accessing the Logs

기본적으로 JobManager와 TaskManager는 각 pod에서 콘솔과 /opt/flink/log에 동시에 로그를 출력합니다. STDOUT와 STDERR 출력은 콘솔로만 리다이렉트됩니다. 다음으로 접근할 수 있습니다:

$ kubectl logs <pod-name>

pod가 실행 중이라면 kubectl exec -it <pod-name> bash를 사용해 터널링하여 로그를 보거나 프로세스를 디버깅할 수도 있습니다.

Accessing the Logs of the TaskManagers

Flink는 리소스를 낭비하지 않기 위해 유휴 상태의 TaskManager를 자동으로 해제합니다. 이 동작 때문에 해당 pod의 로그에 접근하기가 더 어려워질 수 있습니다. [resourcemanager.taskmanager-timeout]을 구성하여 유휴 TaskManager가 해제되기까지의 시간을 늘리면 로그 파일을 조사할 시간을 더 확보할 수 있습니다.

Changing the Log Level Dynamically

로거를 [detect configuration changes automatically]로 구성했다면 해당 ConfigMap을 변경하여 로그 레벨을 동적으로 조정할 수 있습니다(클러스터 id가 my-first-flink-cluster라고 가정):

$ kubectl edit cm flink-config-my-first-flink-cluster

Using Plugins

[plugins]를 사용하려면 Flink JobManager/TaskManager pod의 올바른 위치에 복사해야 합니다. 볼륨을 마운트하거나 커스텀 Docker 이미지를 만들지 않고도 [built-in plugins]를 사용할 수 있습니다. 예를 들어 다음 명령으로 Flink 세션 클러스터에서 S3 플러그인을 활성화합니다:

$ ./bin/kubernetes-session.sh
    -Dcontainerized.master.env.ENABLE_BUILT_IN_PLUGINS=flink-s3-fs-hadoop-2.3.0.jar \
    -Dcontainerized.taskmanager.env.ENABLE_BUILT_IN_PLUGINS=flink-s3-fs-hadoop-2.3.0.jar

Custom Docker Image

커스텀 Docker 이미지를 사용하려면 kubernetes.container.image.ref 구성 옵션으로 지정할 수 있습니다. Flink 커뮤니티는 좋은 시작점이 될 수 있는 풍부한 [Flink Docker image]를 제공합니다. 플러그인 활성화, 의존성 추가 등의 방법은 [how to customize Flink's Docker image]를 참조하세요.

Using Secrets

[Kubernetes Secrets]는 비밀번호, 토큰, 키와 같은 소량의 민감한 데이터를 포함하는 객체입니다. 이러한 정보는 그렇지 않으면 pod 사양이나 이미지에 넣어야 할 수도 있습니다. 쿠버네티스의 Flink는 두 가지 방법으로 Secrets를 사용할 수 있습니다:

• pod에서 파일로 Secrets를 사용;

• 환경 변수로 Secrets를 사용;

Using Secrets as Files From a Pod

다음 명령은 시작된 pod의 /path/to/secret 경로 아래에 mysecret 시크릿을 마운트합니다:

$ ./bin/kubernetes-session.sh -Dkubernetes.secrets=mysecret:/path/to/secret

mysecret 시크릿의 사용자 이름과 비밀번호는 /path/to/secret/username과 /path/to/secret/password 파일에 저장되어 있습니다. 자세한 내용은 [official Kubernetes documentation]을 참조하세요.

Using Secrets as Environment Variables

다음 명령은 시작된 pod에서 mysecret 시크릿을 환경 변수로 노출합니다:

$ ./bin/kubernetes-session.sh -Dkubernetes.env.secretKeyRef=\
    env:SECRET_USERNAME,secret:mysecret,key:username;\
    env:SECRET_PASSWORD,secret:mysecret,key:password

환경 변수 SECRET_USERNAME에는 사용자 이름이, SECRET_PASSWORD에는 mysecret 시크릿의 비밀번호가 들어갑니다. 자세한 내용은 [official Kubernetes documentation]을 참조하세요.

Mounting Persistent Volume Claims

[Kubernetes PersistentVolumeClaims (PVCs)]는 쿠버네티스에서 영구 스토리지를 요청하고 사용하는 방법을 제공합니다. 쿠버네티스의 Flink는 구성 옵션을 통해 PVC를 JobManager 및 TaskManager pod에 직접 마운트하는 것을 지원합니다.

Configuration Options

Flink는 PVC를 마운트하기 위한 두 가지 구성 옵션을 제공합니다:

Configuration Option	Type	Default	Description
kubernetes.persistent-volume-claims	Map<String, String>	(none)	Flink 컨테이너에 마운트할 사용자 지정 PersistentVolumeClaim입니다. 값은 pvc-name:/mount/path 형식이어야 합니다. 여러 PVC는 쉼표로 구분하여 지정할 수 있습니다.
kubernetes.persistent-volume-claim-read-only	Boolean	false	PersistentVolumeClaim을 읽기 전용으로 마운트할지 여부입니다. true로 설정하면 모든 PVC가 읽기 전용으로 마운트됩니다.

Usage Examples

다음 명령은 시작된 pod의 /opt/flink/checkpoints 경로에 checkpoint-pvc PVC를 마운트합니다:

$ ./bin/kubernetes-session.sh \
    -Dkubernetes.cluster-id=my-session-cluster \
    -Dkubernetes.persistent-volume-claims=checkpoint-pvc:/opt/flink/checkpoints

쉼표로 구분하여 여러 PVC를 마운트할 수 있습니다:

$ ./bin/kubernetes-session.sh \
    -Dkubernetes.cluster-id=my-session-cluster \
    -Dkubernetes.persistent-volume-claims=checkpoint-pvc:/opt/flink/checkpoints,data-pvc:/opt/flink/data

PVC를 읽기 전용으로 마운트하려면 (공유 참조 데이터에 유용):

$ ./bin/kubernetes-session.sh \
    -Dkubernetes.cluster-id=my-session-cluster \
    -Dkubernetes.persistent-volume-claims=shared-data:/opt/flink/shared \
    -Dkubernetes.persistent-volume-claim-read-only=true

Example: Using PVC for Checkpoint Storage

PVC를 체크포인트 저장에 사용하는 것은 일반적인 사례입니다. 먼저 쿠버네티스 클러스터에 PVC를 생성합니다:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: flink-checkpoints-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard

그런 다음 체크포인트 저장을 위해 PVC가 마운트된 Flink 클러스터를 시작합니다:

$ ./bin/flink run \
    --target kubernetes-application \
    -Dkubernetes.cluster-id=my-checkpoint-cluster \
    -Dkubernetes.container.image=flink:latest \
    -Dkubernetes.persistent-volume-claims=flink-checkpoints-pvc:/opt/flink/checkpoints \
    -Dstate.checkpoints.dir=file:///opt/flink/checkpoints \
    local:///opt/flink/usrlib/my-flink-job.jar

Prerequisites

• PVC는 배포 전에 Flink 클러스터와 같은 네임스페이스에 존재해야 합니다.

• PVC는 적절한 접근 모드를 가져야 합니다:

• ReadWriteOnce (RWO): 단일 pod 접근용. standalone JobManager 배포에 적합합니다.

• ReadWriteMany (RWX): 여러 pod가 동일한 스토리지에 접근하는 경우용. HA 구성이나 JobManager와 TaskManager가 모두 동일한 스토리지에 써야 할 때 권장됩니다.

• ReadOnlyMany (ROX): 여러 pod의 읽기 전용 접근용. 공유 참조 데이터에 적합합니다.

여러 JobManager가 있는 고가용성(HA) 구성이나 JobManager와 TaskManager가 모두 동일한 스토리지에 쓰기 접근이 필요한 경우, PVC가 ReadWriteMany (RWX) 접근 모드를 지원하는지 확인하세요. 이러한 시나리오에서 ReadWriteOnce (RWO)를 사용하면 마운트 실패나 I/O 오류가 발생할 수 있습니다.

kubernetes.persistent-volume-claim-read-only 옵션은 구성된 모든 PVC에 전역적으로 적용됩니다. PVC마다 다른 접근 모드가 필요하다면(예: 체크포인트는 읽기-쓰기, 참조 데이터는 읽기 전용) [Pod Templates]를 사용하여 세분화된 볼륨 구성을 정의하세요.

High-Availability on Kubernetes

쿠버네티스에서 고가용성을 위해 [existing high availability services]를 사용할 수 있습니다.

[kubernetes.jobmanager.replicas] 값을 1보다 크게 구성하여 대기(standby) JobManager를 시작합니다. 이렇게 하면 더 빠른 복구를 달성할 수 있습니다. 대기 JobManager를 시작할 때는 고가용성을 활성화해야 합니다.

Manual Resource Cleanup

Flink는 [Kubernetes OwnerReference's]를 사용하여 모든 클러스터 컴포넌트를 정리합니다. ConfigMap, Service, Pod를 포함한 Flink가 생성한 모든 리소스는 deployment/<cluster-id>로 OwnerReference가 설정됩니다. deployment가 삭제되면 관련 리소스도 모두 자동으로 삭제됩니다.

$ kubectl delete deployment/<cluster-id>

Supported Kubernetes Versions

현재 모든 쿠버네티스 버전 >= 1.9가 지원됩니다.

Namespaces

[Namespaces in Kubernetes]는 [resource quotas]를 통해 클러스터 리소스를 여러 사용자에게 나눕니다. 쿠버네티스의 Flink는 네임스페이스를 사용하여 Flink 클러스터를 실행할 수 있습니다. 네임스페이스는 [kubernetes.namespace]로 구성할 수 있습니다.

RBAC

역할 기반 접근 제어([RBAC])는 기업 내 개별 사용자의 역할에 따라 컴퓨팅 또는 네트워크 리소스에 대한 접근을 규제하는 방법입니다. 사용자는 JobManager가 쿠버네티스 클러스터 내의 Kubernetes API 서버에 접근할 때 사용하는 RBAC 역할과 service account를 구성할 수 있습니다.

모든 네임스페이스에는 기본 service account가 있습니다. 그러나 default service account는 쿠버네티스 클러스터 내에서 pod를 생성하거나 삭제할 권한이 없을 수 있습니다. 사용자는 default service account의 권한을 업데이트하거나 올바른 역할이 바인딩된 다른 service account를 지정해야 할 수 있습니다.

$ kubectl create clusterrolebinding flink-role-binding-default --clusterrole=edit --serviceaccount=default:default

default service account를 사용하지 않으려면 다음 명령으로 새 flink-service-account service account를 만들고 역할 바인딩을 설정합니다. 그런 다음 -Dkubernetes.service-account=flink-service-account 구성 옵션을 사용해 TaskManager pod와 리더 ConfigMap을 생성·삭제하는 데 사용되는 JobManager pod의 service account를 구성합니다. 이는 또한 TaskManager가 리더 ConfigMap을 감시하여 JobManager 및 ResourceManager의 주소를 검색할 수 있게 해줍니다.

$ kubectl create serviceaccount flink-service-account
$ kubectl create clusterrolebinding flink-role-binding-flink --clusterrole=edit --serviceaccount=default:flink-service-account

자세한 내용은 쿠버네티스 공식 문서의 [RBAC Authorization]을 참조하세요.

Pod Template

Flink는 템플릿 파일을 통해 JobManager 및 TaskManager pod를 정의할 수 있게 합니다. 이는 Flink [Kubernetes config options]가 직접 지원하지 않는 고급 기능을 지원하게 해줍니다. [kubernetes.pod-template-file.default]를 사용하여 pod 정의를 포함한 로컬 파일을 지정합니다. 이 파일은 JobManager와 TaskManager를 초기화하는 데 사용됩니다. 기본 컨테이너는 flink-main-container 이름으로 정의해야 합니다. 자세한 내용은 [pod template example]을 참조하세요.

Fields Overwritten by Flink

pod 템플릿의 일부 필드는 Flink에 의해 덮어쓰여집니다. 유효 필드 값을 결정하는 메커니즘은 다음과 같이 분류됩니다:

• Defined by Flink: 사용자가 구성할 수 없습니다.

• Defined by the user: 사용자가 자유롭게 값을 지정할 수 있습니다. Flink 프레임워크는 추가 값을 설정하지 않으며, 유효 값은 구성 옵션과 템플릿에서 도출됩니다.

우선순위 순서: 먼저 명시적 구성 옵션 값을 취하고, 그다음 pod 템플릿의 값, 마지막으로 아무것도 지정되지 않으면 구성 옵션의 기본값을 사용합니다.

• Merged with Flink: Flink는 사용자가 정의한 값과 설정을 병합합니다("Defined by the user"의 우선순위 순서 참조). 동일한 이름의 필드가 있으면 Flink 값이 우선합니다.

덮어쓰여질 pod 필드의 전체 목록은 아래 표를 참조하세요. 표에 나열되지 않은 pod 템플릿의 모든 필드는 영향을 받지 않습니다.

Pod Metadata

Key	Category	Related Config Options	Description
name	Defined by Flink		JobManager pod 이름은 [kubernetes.cluster-id]로 정의된 deployment로 덮어써집니다. TaskManager pod 이름은 Flink ResourceManager가 생성한 <clusterID>-<attempt>-<index> 패턴으로 덮어써집니다.
namespace	Defined by the user	[kubernetes.namespace]	JobManager deployment와 TaskManager pod 모두 사용자 지정 네임스페이스에 생성됩니다.
ownerReferences	Defined by Flink		JobManager 및 TaskManager pod의 owner reference는 항상 JobManager deployment로 설정됩니다. deployment가 삭제될 시점을 제어하려면 [kubernetes.jobmanager.owner.reference]를 사용하세요.
annotations	Defined by the user	[kubernetes.jobmanager.annotations], [kubernetes.taskmanager.annotations]	Flink는 Flink 구성 옵션으로 지정된 추가 어노테이션을 추가합니다.
labels	Merged with Flink	[kubernetes.jobmanager.labels], [kubernetes.taskmanager.labels]	Flink는 사용자 정의 값에 일부 내부 레이블을 추가합니다.

Pod Spec

Key	Category	Related Config Options	Description
imagePullSecrets	Defined by the user	[kubernetes.container.image.pull-secrets]	Flink는 Flink 구성 옵션으로 지정된 추가 pull secrets를 추가합니다.
nodeSelector	Defined by the user	[kubernetes.jobmanager.node-selector], [kubernetes.taskmanager.node-selector]	Flink는 Flink 구성 옵션으로 지정된 추가 node selectors를 추가합니다.
tolerations	Defined by the user	[kubernetes.jobmanager.tolerations], [kubernetes.taskmanager.tolerations]	Flink는 Flink 구성 옵션으로 지정된 추가 tolerations를 추가합니다.
restartPolicy	Defined by Flink		JobManager pod는 "always", TaskManager pod는 "never"입니다. JobManager pod는 항상 deployment에 의해 재시작됩니다. TaskManager pod는 재시작되어서는 안 됩니다.
serviceAccount	Defined by the user	[kubernetes.service-account]	JobManager 및 TaskManager pod는 사용자 정의 service account로 생성됩니다.
volumes	Merged with Flink		Flink는 Flink 구성과 hadoop 구성을 전달하는 데 필요한 내부 ConfigMap 볼륨(예: flink-config-volume, hadoop-config-volume)을 추가합니다.

Main Container Spec

Key	Category	Related Config Options	Description
env	Merged with Flink	[containerized.master.env.{ENV_NAME}], [containerized.taskmanager.env.{ENV_NAME}]	Flink는 사용자 정의 값에 일부 내부 환경 변수를 추가합니다.
image	Defined by the user	[kubernetes.container.image.ref]	컨테이너 이미지는 사용자 정의 값에 대해 정의된 우선순위 순서에 따라 결정됩니다.
imagePullPolicy	Defined by the user	[kubernetes.container.image.pull-policy]	컨테이너 이미지 pull 정책은 사용자 정의 값에 대해 정의된 우선순위 순서에 따라 결정됩니다.
name	Defined by Flink		컨테이너 이름은 Flink에 의해 "flink-main-container"로 덮어써집니다.
resources	Defined by the user	Memory: [jobmanager.memory.process.size], [taskmanager.memory.process.size], CPU: [kubernetes.jobmanager.cpu], [kubernetes.taskmanager.cpu]	메모리와 CPU 리소스(request 및 limit 포함)는 Flink 구성 옵션으로 덮어써집니다. 다른 모든 리소스(예: ephemeral-storage)는 유지됩니다.
containerPorts	Merged with Flink		Flink는 일부 내부 컨테이너 포트(예: rest, jobmanager-rpc, blob, taskmanager-rpc)를 추가합니다.
volumeMounts	Merged with Flink		Flink는 Flink 구성과 hadoop 구성을 전달하는 데 필요한 내부 볼륨 마운트(예: flink-config-volume, hadoop-config-volume)를 추가합니다.

Example of Pod Template

pod-template.yaml

apiVersion: v1
kind: Pod
metadata:
  name: jobmanager-pod-template
spec:
  initContainers:
    - name: artifacts-fetcher
      image: busybox:latest
      # Use wget or other tools to get user jars from remote storage
      command: [ 'wget', 'https://path/of/StateMachineExample.jar', '-O', '/flink-artifact/myjob.jar' ]
      volumeMounts:
        - mountPath: /flink-artifact
          name: flink-artifact
  containers:
    # Do not change the main container name
    - name: flink-main-container
      resources:
        requests:
          ephemeral-storage: 2048Mi
        limits:
          ephemeral-storage: 2048Mi
      volumeMounts:
        - mountPath: /opt/flink/volumes/hostpath
          name: flink-volume-hostpath
        - mountPath: /opt/flink/artifacts
          name: flink-artifact
        - mountPath: /opt/flink/log
          name: flink-logs
      # Use sidecar container to push logs to remote storage or do some other debugging things
    - name: sidecar-log-collector
      image: sidecar-log-collector:latest
      command: [ 'command-to-upload', '/remote/path/of/flink-logs/' ]
      volumeMounts:
        - mountPath: /flink-logs
          name: flink-logs
  volumes:
    - name: flink-volume-hostpath
      hostPath:
        path: /tmp
        type: Directory
    - name: flink-artifact
      emptyDir: { }
    - name: flink-logs
      emptyDir: { }

User jars & Classpath

쿠버네티스에 Flink를 네이티브하게 배포할 때 다음 jar는 사용자 jar로 인식되어 사용자 classpath에 포함됩니다:

• Session Mode: 시작 명령에 지정된 JAR 파일.
• Application Mode: 시작 명령에 지정된 JAR 파일과 Flink의 usrlib 폴더에 있는 모든 JAR 파일.

자세한 내용은 [Debugging Classloading Docs]를 참조하세요.

더 알아보기 (Learn more)

• Application Mode
• Session Mode
• Kubernetes operator
• Flink on Kubernetes 설정 옵션