kubeflow 1.9 마이그레이션

kubeflow 1.8버전에서 1.9버전으로 마이그레이션을 진행하면서 변경사항 때문에 발생했었던 문제와 해결했었던 방법을 정리해보려고 합니다.

 

 

저는 kubeflow manifest방식으로 kubeflow를 설치하였습니다.

https://github.com/kubeflow/manifests

GitHub - kubeflow/manifests: A repository for Kustomize manifests

 

 

kubeflow manifest를 설치하면서 어려웠던 점은 kubeflow는 기본적으로 Istio Injection이 되어있기에, Istio에 익숙하지 않으면 사용자가 원하는 방법대로 서비스를 노출하고 라우팅하기 쉽지 않다는 것이었습니다.

 

 

기본적으로 kubeflow dashboard의 요소들은 Istio의 VirtualService 리소스가 기본적으로 kubeflow manifest에 포함되어 있지만, 그이외의 ml-pipeline 서비스나 내장되어있는 minio의 경우에는 사용자가 알아서 해당 서비스에 접근할 수 있는 리소스를 생성해 주어야 합니다.

 

 

또한 kubeflow가 1.9버전으로 올라가면서 인증방식이 oidc-authservice에서 OAuth2-proxy로 변경되었다는 점 역시 저를 곤란하게 했었는데요.

 

 

kubeflow manifest의 경우 kubeflow dashboard의 서비스들은 Istio-ingressgateway를 통해 dex인증을 받은 후 JWT를 이용하여 OAuth2-Proxy을 거친 후에 해당 서비스에 접근할 수 있는데, ml-pipeline이나 minio는 dex인증을 지원하지 않는 것 같습니다. (이 부분에서는 틀린내용이 있다면 알려주시면 감사하겠습니다.)

 

---

1. minio와 ml-pipeline 서비스에 접근할 수 없었던 문제

 

kubeflow를 1.9버전으로 마이그레이션을 진행하면서 가장 곤란했던 문제가, minio와 ml-pipeline (ui 아닙니다) 서비스에 접근을 할 수 없었던 문제였습니다.

 

기존에는 ingress를 통해 접근을 하였지만, 이상하게 1.9버전으로 올라가면서 해당 서비스에 접근할 수 없었습니다.

 

원인은 1.9버전에 추가된 networkPolicy 리소스 때문이었습니다.

 

networkPolicy에서 podSelector과 namespaceSelector이 제가 외부에서 해당하는 pod로 연결하는 것을 막고 있었습니다.

 

기본 값은 Istio-system namespace이 source인 요청만 받는 상태입니다.

 

minio와 ml-pipeline은 Istio-sytem namespace에 속한 Istio-ingressgateway를 거쳐 dex 인증을 받을 수 없으므로, 적절하게 규칙을 수정하거나 제거하는 방법으로 이 문제를 해결할 수 있습니다.

 

kustomization.yaml

patches:
  - target:
        kind: NetworkPolicy
        name: minio
        namespace: kubeflow
    patch: |-
        - op: replace
          path: /spec/ingress/0/from
          value:
            - namespaceSelector: {}
            - podSelector: {}

  - target:
        kind: NetworkPolicy
        name: ml-pipeline
        namespace: kubeflow
    patch: |-
        - op: replace
          path: /spec/ingress/0/from
          value:
            - namespaceSelector: {}
            - podSelector: {}

 

---

 

2. minio 콘솔 로그인이 안되는 현상

 

1번 설정을 통해 minio서비스로 접근까지는 성공하였지만, 콘솔 로그인이 진행되지 않는 문제가 있었습니다.

 

로그인을 진행하면 minio인증을 성공하지만 곧바로 다시 콘솔 로그인 페이지로 redirect되는 현상이 있었는데요.

 

이 부분은 1.9버전으로 바뀌게 되면서 Istio버전도 오르게 되어, 기존 kubeflow manifest에 포함되어 있지 않던 requestAuthentication 리소스의 인증 과정에서 오류가 발생하던 것이었습니다.

 

오류 메시지는 issuer이 일치하지 않는다는 것이었는데, 어떤 부분에서 JWT인증이 실패하는지 정확한 원인을 찾진 못했습니다. (아시는 분 있으시다면 댓글 부탁드립니다.)

 

그래서 저는 임시방편으로 minio의 경우에는 Istio-Injection을 비활성하여 해당 requestAuthentication 인증 과정이 일어나지 않게 수정하였습니다.

 

Istio는 namespace를 기준으로 생성되는 모든 pod들에 Istio-injection을 수행하여 istio-proxy 사이드카 컨테이너를 생성하게 됩니다.

 

kustomization.yaml

# Istio Injection disabled
patches:
  - target:
        kind: Deployment
        name: minio
        namespace: kubeflow
    patch: |-
        - op: replace
          path: /spec/selector/matchLabels
          value:
            app: minio
            application-crd-id: kubeflow-pipelines
            sidecar.istio.io/inject: "false"
        - op: replace
          path: /spec/template/metadata/labels
          value:
            app: minio
            application-crd-id: kubeflow-pipelines
            sidecar.istio.io/inject: "false"

 

 

---

 

3. kubeflow dashboard 다중로그인이 허용되지 않는 문제

 

기존에는 하나의 dex 인증정보를 가지고 여러 클라이언트가 dashboard에 접근할 수 있었는데요.

 

kubeflow 1.9버전으로 변경되면서 인증방식이 OAuth2-Proxy로 변경되어 더 이상 다중 클라이언트가 허용되지 않게 되었습니다.

 

 

OAuth2-Proxy는 동일한 프록시 인스턴스에 대해 여러 클라이언트가 허용되지 않습니다.

 

이 부분에서는 뭔가 인증을 우회하거나 동일한 프록시 인스턴스에 대해 다중 클라이언트를 허용하는 방법 외에 kubeflow에서 제공하는 협업 기능 contributor를 적용하기로 하였습니다.

 

 

하나의 kubeflow profile(namespace)에서 한 명의 admin과 여러 명의 contributor가 동시에 작업할 수 있는 기능입니다.

 

contributor를 추가하는 방법은 kubeflow 공식문서를 참고하시길 바랍니다.

 

https://www.kubeflow.org/docs/components/central-dash/profiles/

Profiles and Namespaces

 

 

---

 

kubeflow가 1.9버전으로 버전 업이 되면서 인증이나 정책처럼 보안적인 측면이 더욱 강화되었습니다.

 

물론 보안을 강화하고 관리하는건 굉장히 중요합니다. 하지만, 연구자들이 kubeflow를 빠르고 쉽게 사용하기엔 조금 더 어려운 부분이 있지 않나 싶습니다. (물론 kubeflow manifest는 고급 사용자들을 위한 것이긴 합니다...)