HADOOP_USER_NAME 처럼 네임스페이스를 단일 환경변수로 박는 것은 없다. fs.defaultFS 는 core-site.xml 에서 읽는다. 방법은 세 가지다.
hdfs dfs -ls hdfs://<nameservice>/ # URI 로 직접 지정 (1회성)
hdfs dfs -D fs.defaultFS=hdfs://<nameservice>/ -ls / # -D 로 오버라이드
export HADOOP_CONF_DIR=/home/cdsw/ext-conf # 별도 conf 디렉터리 (세션에 영구)
완전히 별개의 외부 클러스터라면 그 클러스터 전용 conf 디렉터리를 만들고 HADOOP_CONF_DIR 로 박는 것이 가장 깔끔하다. 세션 기본 /etc/hadoop/conf 는 건드리지 않는다. nameservice 이름만 던지면 클라이언트가 그 뒤의 NameNode 를 몰라 UnknownHostException 이 나므로 hdfs-site.xml 에 외부 nameservice 정의를 넣어야 한다.
<!-- /home/cdsw/ext-conf/core-site.xml -->
<configuration>
<property><name>fs.defaultFS</name><value>hdfs://extns</value></property>
</configuration>
<!-- /home/cdsw/ext-conf/hdfs-site.xml (외부 클러스터 값을 그대로 복사) -->
<configuration>
<property><name>dfs.nameservices</name><value>extns</value></property>
<property><name>dfs.ha.namenodes.extns</name><value>nn1,nn2</value></property>
<property><name>dfs.namenode.rpc-address.extns.nn1</name><value>ext-nn1.example.com:8020</value></property>
<property><name>dfs.namenode.rpc-address.extns.nn2</name><value>ext-nn2.example.com:8020</value></property>
<property>
<name>dfs.client.failover.proxy.provider.extns</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
</configuration>
Project Settings → Advanced → Environment Variables 에 HADOOP_CONF_DIR=/home/cdsw/ext-conf 와 HADOOP_USER_NAME 을 넣으면 모든 세션에 적용된다. hdfs getconf -confKey fs.defaultFS 로 검증한다.
HDFS HA 는 NameNode 앞에 로드밸런서를 두는 구조가 아니다. 클라이언트가 두 NameNode 주소를 모두 갖고 ConfiguredFailoverProxyProvider 가 시도-실패-전환하므로, hostname 이 DNS 로 풀리지 않으면 두 NameNode 각각의 IP 를 rpc-address 에 적어도 HA 가 유지된다. 단 Kerberos 클러스터는 SPN 이 hdfs/_HOST@REALM 이라 IP 접속 시 GSS 인증이 깨지므로 hostname 과 정 · 역방향 DNS(또는 /etc/hosts) 를 맞춰야 한다. -ls 는 NameNode 만 닿아도 되지만 -cat/-get 은 DataNode 포트(1004/1019 또는 9866) 로 직접 붙으므로 CAI 파드에서 그 포트까지 열려 있어야 한다.
레거시 Custom Engine 은 deprecated 이며 Custom ML Runtime 방식을 쓴다. 흐름은 Dockerfile 작성 → 빌드 → 레지스트리 push → Runtime Catalog 등록 → 세션에서 선택이다. 베이스는 Cloudera 공식 ML Runtime 에 패키지만 얹거나, cloudera/ml-runtimes 의 PBJ(Powered by Jupyter) Dockerfile 을 청사진으로 OS · 커널까지 직접 구성한다.
FROM docker.repository.cloudera.com/cloudera/cdsw/ml-runtime-workbench-python3.10-standard:2024.10.1-b8
USER root
RUN apt-get update && apt-get install -y --no-install-recommends telnet \
&& apt-get clean && rm -rf /var/lib/apt/lists/*
RUN pip install --no-cache-dir scikit-learn pandas
# Runtime 메타데이터 (필수). Edition 은 공식 값과 겹치지 않게 바꾼다
ENV ML_RUNTIME_EDITION="MyCompany Edition" \
ML_RUNTIME_SHORT_VERSION="1.0" \
ML_RUNTIME_MAINTENANCE_VERSION=1 \
ML_RUNTIME_DESCRIPTION="sklearn + pandas + telnet"
ENV ML_RUNTIME_FULL_VERSION="${ML_RUNTIME_SHORT_VERSION}.${ML_RUNTIME_MAINTENANCE_VERSION}"
LABEL com.cloudera.ml.runtime.edition=$ML_RUNTIME_EDITION \
com.cloudera.ml.runtime.full-version=$ML_RUNTIME_FULL_VERSION \
com.cloudera.ml.runtime.short-version=$ML_RUNTIME_SHORT_VERSION \
com.cloudera.ml.runtime.maintenance-version=$ML_RUNTIME_MAINTENANCE_VERSION \
com.cloudera.ml.runtime.description=$ML_RUNTIME_DESCRIPTION \
com.cloudera.ml.runtime.runtime-metadata-version=1
USER 8536
PBJ 를 처음부터 만들 때는 ML_RUNTIME_EDITOR, ML_RUNTIME_KERNEL 과 대응 LABEL(com.cloudera.ml.runtime.editor, ...kernel) 도 채운다. 등록 시 "invalid runtime" 류 오류는 거의 LABEL/ENV 메타데이터 누락이고, 세션이 뜨지 않으면 마지막에 비-root UID(8536) 로 복귀했는지 본다.
docker build -t <registry>/<ns>/cai-custom-runtime:1.0.1 -f Dockerfile .
docker push <registry>/<ns>/cai-custom-runtime:1.0.1
UI 의 Runtime Catalog → Add Runtime 에 이미지 경로를 넣어 등록하고, 프로젝트 기본 Runtime 으로 지정할 수 있다. private registry 자격증명은 Dockerfile 이 아니라 워크벤치의 registry credential 설정에 둔다.