Linux VM의 마이그레이션 계획 맞춤설정

마이그레이션 계획을 실행하기 전에 이를 검토하고 선택적으로 맞춤설정해야 합니다. 마이그레이션 계획의 세부정보는 소스 VM에서 워크로드 컨테이너 아티팩트를 추출하고 컨테이너 이미지를 프로덕션 클러스터와 같은 다른 클러스터에 배포하는 데 사용할 수 있는 Kubernetes 배포 파일을 생성하는 데 사용됩니다.

이 페이지에서는 마이그레이션을 실행하고 배포 아티팩트를 생성하기 전에 고려할 수 있는 마이그레이션 계획의 콘텐츠와 종류를 설명합니다.

시작하기 전에

이 주제에서는 사용자가 이미 마이그레이션 계획을 만들었고 해당 마이그레이션 계획 파일이 있다고 가정합니다.

마이그레이션 계획 수정

파일 시스템을 복사하고 분석한 후 지정된 출력 경로 ANALYSIS_OUTPUT_PATH/config.yaml에 생성된 새 디렉터리에서 마이그레이션 계획을 찾을 수 있습니다.

필요에 따라 마이그레이션 계획을 수정하고 변경사항을 저장합니다.

마이그레이션 계획 세부정보와 안내를 검토하여 필요에 따라 정보를 추가하세요. 특히 다음 섹션을 수정하는 것이 좋습니다.

마이그레이션에서 제외할 콘텐츠 지정

기본적으로 Migrate to Containers는 GKE 컨텍스트와 관련이 없는 일반적인 VM 콘텐츠를 제외합니다. 이 필터를 맞춤설정할 수 있습니다.

filters 필드 값은 마이그레이션에서 제외되어야 하며 컨테이너 이미지의 일부가 아닌 경로를 나열합니다. 필드의 값은 전송할 파일과 건너뛸 파일을 지정하는 rsync 필터 규칙을 나열합니다. 각 경로 및 파일 앞에 마이너스 기호가 있으면 목록의 항목을 마이그레이션에서 제외하도록 지정됩니다. 이 목록은 YAML의 행 순서에 따라 처리되며 이에 따라 제외/포함이 평가됩니다.

rsync 필터 규칙 자세히 알아보기

Docker 이미지에 포함하기에 너무 큰 파일은 YAML 파일에 나열됩니다. 이렇게 하면 1GB보다 큰 파일에 플래그를 지정하는 것이 좋습니다. Docker 이미지가 너무 크거나 15GB보다 크면 마이그레이션 중에 실패할 수 있습니다.

YAML 목록을 수정하여 경로를 추가하거나 삭제할 수 있습니다. 다음 예시 YAML에는 예시 제외뿐만 아니라 대용량 파일과 희소 파일에 대한 알림이 포함되어 있습니다. 인라인 안내에 따라 다음 작업 중 하나를 수행합니다.

• 감지된 폴더를 주석 처리 삭제하고 전역 필터 섹션 아래에 배치하여 제외합니다.
• 감지된 폴더를 주석 처리 삭제하고 데이터 폴더 섹션 아래에 배치하여 영구 볼륨으로 이동합니다.

같은 방식으로 감지된 희소 파일을 제외하거나 이동할 수도 있습니다.

  global:
    # Files and directories to exclude from the migration, in rsync format.
    filters:
      - "- *.swp"
      - "- /etc/fstab"
      - "- /boot/"
      - "- /tmp/*"
      - "- /var/log/*.log*"
      - "- /var/log/*/*.log*"
      - "- /var/cache/*"

    ## The data folders below are too large to be included in the docker image.
    ## Consider uncommenting and placing them under either the global filters
    ## or the data folder section.
      # - '- /a' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/c' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

    ## Sparse files will fail the run of a docker image. Consider excluding the below
    ## detected files and any other sparse files by uncommenting and placing them in 
    ## the global filters section, or export them to a persistent volume by specifying
    ## them in the data folder section.
      # - '- /a/b' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/d' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

컨테이너 이미지의 이름 설정

image 섹션의 name 필드 값은 컨테이너에 사용되는 마이그레이션된 VM에서 생성된 이미지의 이름을 정의합니다. 다른 이름을 사용하려는 경우 이 값을 변경하면 됩니다.

image:
     # Review and set the name for runnable container image.
     name: linux-system

서비스 목록 맞춤설정

기본적으로 Migrate to Containers는 사용자가 컨테이너로 마이그레이션할 때 VM에서 불필요한 서비스를 중지합니다. 일부 경우에 이러한 서비스는 마이그레이션된 컨테이너에 문제를 일으킬 수도 있고 컨테이너 컨텍스트에 필요하지 않습니다.

Migrate to Containers에서 자동으로 중지된 서비스와 함께 선택적으로 다른 서비스를 중지할 수 있습니다.

• Migrate to Containers는 선택적으로 중지할 수 있는 서비스를 자동으로 검색하고 이를 마이그레이션 계획에 나열합니다. 이러한 서비스(예: ssh 또는 웹 서버)는 마이그레이션된 워크로드에 필요하지 않을 수 있지만 이는 사용자가 판단해야 합니다. 필요한 경우 마이그레이션 계획을 수정하여 이러한 서비스를 사용 중지합니다.

• Migrate to Containers는 소스 VM에서 실행되는 모든 서비스를 나열하지 않습니다. 예를 들어 운영체제 관련 서비스가 생략됩니다. 필요한 경우 마이그레이션 계획을 수정하여 마이그레이션된 컨테이너에서 사용 중지할 자체 서비스 목록을 추가할 수 있습니다.

systemServices 필드는 Migrate to Containers에서 검색한 서비스 목록을 지정합니다. 예를 들면 다음과 같습니다.

    systemServices:
    - enabled: true|false
      name: service-name
      probed: true|false
    - enabled: true|false
      name: service-name
      probed: true|false
      ...

서비스를 사용 중지하려면 enabled를 false로 설정합니다.

Migrate to Containers는 운영체제 관련 서비스와 같은 소스 VM에서 실행되는 모든 서비스를 나열하지 않습니다. 목록에 추가 서비스를 추가할 수도 있습니다. 예를 들어 service2 및 cron 서비스를 사용 중지하려면 다음 안내를 따르세요.

    systemServices:
    - enabled: true
      name: service1
      probed: false
    - enabled: false
      name: service2
      probed: false
    - enabled: false
      name: cron
      probed: false

마이그레이션을 실행하여 마이그레이션 아티팩트를 생성하면 Migrate to Containers가 blocklist.yaml 파일을 만듭니다. 이 파일에는 마이그레이션 계획의 설정에 따라 사용 중지할 컨테이너 서비스 목록이 나와 있습니다. 예를 들면 다음과 같습니다.

service_list:
- name: disabled-services
  services:
  # Because you used systemServices above to disabled service2 and cron:
  - service2
  - cron

나중에 사용 중지된 서비스 목록을 수정하려면 다음을 수행합니다.

• 마이그레이션 계획의 서비스 목록을 수정합니다.
• 마이그레이션을 실행하여 업데이트된 blocklist.yaml을 포함한 마이그레이션 아티팩트를 다시 생성합니다.

또는 마이그레이션을 실행하여 마이그레이션 아티팩트를 생성한 후 blocklist.yaml 파일을 직접 수정하고 Skaffold를 사용하여 컨테이너 이미지를 빌드 및 배포할 수 있습니다.

서비스 엔드포인트 맞춤설정

마이그레이션 계획에는 마이그레이션된 워크로드에서 제공하는 Kubernetes 서비스를 만드는 데 사용되는 포트와 프로토콜을 정의하는 endpoints 배열이 포함됩니다. 엔드포인트 정의를 추가, 수정, 삭제하여 마이그레이션 계획을 맞춤설정할 수 있습니다.

엔드포인트 포트를 검색하려면 수신 대기 포트를 확인하는 프로그램을 확인하세요.

sudo netstat --programs --listening --tcp --udp [--sctp]

각 서비스 엔드포인트에서 다음 정의를 마이그레이션 계획에 추가합니다.

    endpoints:
    - port: PORT_NUMBER
      protocol: PORT_PROTOCOL
      name: PORT_NAME

각 항목의 의미는 다음과 같습니다.

• PORT_NUMBER는 서비스에 대한 요청이 라우팅되는 컨테이너 포트 번호를 지정합니다.
• PORT_PROTOCOL은 HTTP, HTTPS 또는 TCP와 같은 포트 프로토콜을 지정합니다. 전체 프로토콜 목록은 지원되는 프로토콜을 참조하세요.
• PORT_NAME은 서비스 엔드포인트에 액세스하는 데 사용되는 이름을 지정합니다. Migrate to Containers는 각 생성된 엔드포인트 정의에 대해 고유한 PORT_NAME을 생성합니다.

예를 들어 Migrate to Containers는 다음 엔드포인트를 검색합니다.

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 6379
      protocol: TCP
      name: backend-server-redis

name 속성의 값을 설정하기 위해 Migrate to Containers는 소스 VM 이름(이 예시에서는 backend-server)을 서비스의 프로그램 이름과 결합합니다. 생성된 이름은 Kubernetes 이름 지정 규칙과 호환되며 마이그레이션 계획 내에서 고유합니다. 예를 들어 위의 마이그레이션 계획은 HTTP를 통해 포트 80에서 Nginx를 대상으로 하는 서비스를 만듭니다.

중복 이름의 경우 Migrate to Containers는 카운터 서픽스를 추가합니다. 예를 들어 Nginx가 두 포트와 연결된 경우 두 번째 정의의 name에 -2 서픽스가 추가됩니다.

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 8080
      protocol: HTTPS
      name: backend-server-nginx-2
    - port: 6379
      protocol: TCP
      name: backend-server-redis

마이그레이션을 실행하여 마이그레이션 아티팩트를 생성하면 Migrate to Containers는 각 엔드포인트의 deployment_spec.yaml 파일에 서비스 정의를 만듭니다.

예를 들어 deployment_spec.yaml 파일의 Service 정의는 다음과 같습니다.

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  name: backend-server-nginx
spec:
  ports:
  - port: 80
    protocol: HTTP
    targetPort: 80
  selector:
    app: backend-server
status:
  loadBalancer: {}

NFS 마운트 맞춤설정

Migrate to Containers에는 생성된 마이그레이션 계획의 NFS 마운트가 포함됩니다. 이 정보는 fstab 파일에서 수집되어 마이그레이션 계획의 nfsMounts 배열에 기록됩니다. NFS 마운트 지점 정의를 추가하거나 수정하여 마이그레이션 계획을 맞춤설정할 수 있습니다.

참고: nfsMounts 배열의 항목은 기본적으로 사용 중지되어 있습니다. Migrate to Containers에서 각 NFS 마운트의 deployment_spec.yaml 파일에 항목을 생성하도록 하려면 해당 항목을 사용 설정해야 합니다.

마이그레이션 계획을 생성할 때 Migrate to Containers는 다음을 수행합니다.

• /sys 및 /dev의 NFS 마운트를 무시합니다.
• nfs 또는 nfs4 이외의 유형이 지정된 NFS 마운트를 무시합니다.

마이그레이션 계획의 각 NFS 마운트에는 서버의 IP 주소와 로컬 마운트 경로가 다음과 같은 형식으로 포함됩니다.

    nfsMounts:
    - mountPoint: MOUNT_POINT
      exportedDirectory: DIR_NAME
      nfsServer: IP
      mountOptions:
         - OPTION_1
         - OPTION_2
      enabled: false|true

각 항목의 의미는 다음과 같습니다.

• MOUNT_POINT는 fstab에서 가져온 마운트 지점을 지정합니다.
• DIR_NAME은 공유 디렉터리의 이름을 지정합니다.
• IP은 마운트 지점을 호스팅하는 서버의 IP 주소를 지정합니다.
• OPTION_N은 마운트 지점에 대해 fstab에서 추출한 모든 옵션을 지정합니다.

예를 들어 fstab의 다음 항목의 경우:

<file system>       <mount point>   <type>  <options>   <dump>  <pass>
10.49.232.26:/vol1  /mnt/test       nfs     rw,hard     0       0

Migrate to Containers는 마이그레이션 계획에 다음 항목을 생성합니다.

    nfsMounts:
    - mountPoint: /mnt/test
      exportedDirectory: /vol1
      nfsServer: 10.49.232.26
      mountOptions:
         - rw
         - hard
      enabled: false

nfsMounts 배열의 항목을 처리하도록 Migrate to Containers를 구성하려면 mountPoint 항목의 enabled를 true로 설정합니다. 하나, 일부 또는 모든 mountPoints 항목을 사용 설정하거나, 항목을 수정하거나, 자체 항목을 추가할 수 있습니다.

마이그레이션을 실행하여 마이그레이션 아티팩트를 생성하면 Migrate to Containers가 사용 설정된 NFS 마운트의 deployment_spec.yaml 파일에서 볼륨 및 volumeMounts 정의와 PersistentVolume 및 PersistentVolumeClaim 정의를 만듭니다.

참고: Migrate to Containers를 사용하려면 마이그레이션된 컨테이너 워크로드를 호스팅하는 배포 클러스터에서 NFS 서버에 액세스할 수 있어야 합니다. 하지만 Migrate to Containers에서는 해당 연결을 검증하지 않습니다. 연결 문제가 있는 마이그레이션된 컨테이너는 시작될 수 없고, 문제 해결을 위해 deployment_spec.yaml 파일을 수정해야 합니다. 자세한 내용은 Filestore CSI 드라이버로 Filestore 인스턴스 액세스를 참조하세요.

예를 들어 deployment_spec.yaml 파일의 volumeMounts 정의는 다음과 같습니다.

    spec:
      containers:
          - image: gcr.io/myimage-1/image-name
            name: some-app
            volumeMounts:
                   - mountPath: /sys/fs/cgroup
                     name: cgroups
                   - mountPath: /mnt/test
                     name: nfs-pv

여기서 name 값은 Migrate to Containers에서 생성된 고유 식별자입니다.

다음은 deployment_spec.yaml 파일의 PersistentVolumeClaim 및 PersistentVolume 정의 예시입니다.

apiVersion: v1
kind: PersistentVolumeClaim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Mi
  storageClassName: ""
  volumeName: nfs-pv

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  mountOptions:
    - rw
    - hard
  nfs:
    path: /vol1
    server: 10.49.232.26

Cloud Logging에 기록된 로그 데이터 맞춤설정

일반적으로 소스 VM은 하나 이상의 로그 파일에 정보를 작성합니다. VM 마이그레이션의 일환으로 마이그레이션된 워크로드를 구성하여 Cloud Logging에 해당 로그 정보를 작성합니다.

참고: 이전 출시 버전의 Migrate to Containers에서는 Cloud Logging 로깅 구성에 설명된 대로 대상 워크로드 클러스터에서 ConfigMap을 사용한 로깅 맞춤설정이 지원되었습니다. 이 섹션에서는 logs.yaml 파일을 사용하여 로깅을 구성하는 방법을 설명합니다. logs.yaml 파일이 있으면 ConfigMap으로 정의된 로깅 설정이 무시됩니다.

마이그레이션 계획을 생성하면 Migrate to Containers가 소스 VM의 로그 대상 파일을 자동으로 검색합니다. 그런 다음 Migrate to Containers는 이러한 감지된 파일에 대한 정보를 마이그레이션 계획의 logPaths 영역에 기록합니다.

deployment:
    ...
    logPaths:
    - appName: APP_NAME
      globs:
      - LOG_PATH

예를 들면 다음과 같습니다.

deployment:
    ...
    logPaths:
    - appName: tomcat
      globs:
      - /var/log/tomcat*/catalina.out

마이그레이션 아티팩트를 생성하면 Migrate to Containers가 이제 마이그레이션 계획에서 logs.yaml 파일을 생성합니다. 이 파일에는 소스 VM에서 검색된 로그 파일 목록이 포함됩니다. 예를 들어 위 logsPath 정의에서는 logs.yaml에 다음 항목이 포함됩니다.

logs:
  tomcat:
  - /var/log/tomcat*/catalina.out

이 예시에서 마이그레이션된 워크로드를 배포하면 catalina.out에 기록된 로그 정보가 자동으로 Cloud Logging에 기록됩니다.

각 항목은 로그 행에 다음 형식으로 표시됩니다.

DATE TIME APP_NAME LOG_OUTPUT

다음 예시는 Tomcat의 항목이 있는 양식을 보여줍니다.

2019-09-22 12:43:08.681193976 +0000 UTC tomcat log-output

로깅을 구성하려면 다음 중 하나를 수행하세요.

• 마이그레이션 아티팩트를 생성하기 전에 logPaths 항목을 추가, 삭제, 수정하도록 마이그레이션 계획을 수정합니다. 마이그레이션 아티팩트를 생성할 때 이러한 수정사항이 logs.yaml 파일에 적용됩니다.

• 마이그레이션 아티팩트를 생성한 후 logs 항목을 추가, 삭제, 수정하도록 logs.yaml을 수정합니다.

마이그레이션 계획을 수정하면 아티팩트를 생성할 때마다 수정사항이 logs.yaml에 반영됩니다. logs.yaml을 직접 수정한 후 어떤 이유로든 아티팩트를 다시 생성하면 수정사항을 logs.yaml에 다시 적용해야 합니다.

Linux v2kServiceManager 상태 프로브 설정

Tomcat 웹 서버의 마이그레이션 계획에 프로브를 지정하여 관리형 컨테이너의 다운타임 및 준비 상태를 모니터링할 수 있습니다. 상태 프로브 모니터링은 마이그레이션된 컨테이너의 다운타임을 줄이고 더 나은 모니터링을 제공하는 데 도움이 될 수 있습니다.

알 수 없는 상태에서는 가용성 저하, 거짓양성 가용성 모니터링, 잠재적인 데이터 손실이 발생할 수 있습니다. 상태 프로브가 없으면 kubelet은 컨테이너 상태만 가정할 수 있으며, 준비되지 않은 컨테이너 인스턴스로 트래픽을 전송할 수 있습니다. 이로 인해 트래픽이 손실될 수 있습니다. Kubelet은 고정된 상태의 컨테이너를 감지하지 못할 수도 있으며, 이로 인해 컨테이너가 다시 시작되지 않습니다.

상태 프로브는 컨테이너가 시작될 때 작은 스크립트 문을 실행하여 작동합니다. 이 스크립트는 모든 기간에 사용된 프로브 유형으로 정의된 성공적인 조건을 확인합니다. 기간은 마이그레이션 계획에서 periodSeconds 필드로 정의됩니다. 이러한 스크립트를 수동으로 실행하거나 정의할 수 있습니다.

kubelet 프로브에 대한 자세한 내용은 Kubernetes 문서의 활성, 준비, 시작 프로브 구성을 참조하세요.

구성할 수 있는 프로브에는 두 가지 유형이 있습니다. 두 프로브 모두 probe-v1-core 참조에 정의된 probe-v1-core이며 container-v1-core의 해당 필드와 동일한 함수를 공유합니다.

• 활성 프로브 - 활성 프로브는 컨테이너를 다시 시작할 시점을 파악하는 데 사용됩니다.
  참고: 문제가 발생하거나 비정상 상태가 되면 컨테이너의 프로세스가 자체적으로 비정상 종료될 수 있는 경우 활성 여부 프로브가 필요하지 않습니다. kubelet은 포드의 restartPolicy에 따라 자동으로 올바른 작업을 수행합니다.
• 준비 프로브 - 준비 프로브는 컨테이너가 트래픽을 수락할 준비가 된 시점을 파악하는 데 사용됩니다. 프로브가 성공한 경우에만 포드에 트래픽 전송을 시작하려면 준비 프로브를 지정합니다. 준비 프로브는 활성 프로브와 유사하게 작동할 수 있지만 이 사양의 준비 프로브에서는 포드가 트래픽을 수신하지 않고 시작하며 프로브가 성공한 후에만 트래픽을 수신하기 시작함을 나타냅니다.

검색 후에는 프로브 구성이 마이그레이션 계획에 추가됩니다. 프로브는 아래와 같이 기본 구성에서 사용할 수 있습니다. 프로브를 사용 중지하려면 yaml에서 probes 섹션을 삭제합니다.

deployment:
  probes:
    livenessProbe:
      exec:
        command:
        - /ko-app/service-manager-runtime
        - /probe

    readinessProbe:
      exec:
        command:
        - gamma
        - /probe
      initialDelaySeconds: 60
      periodSeconds: 5

image:
  # Disable system services that do not need to be executed at the migrated workload containers.
  # Enable the 'probed' property to include system services in the container health checks.
  systemServices:
  - enabled: true
    name: apache2
    probed: true
  - enabled: true
    name: atd
    probed: false 

기본적으로 모든 서비스 프로브는 사용 중지되어 있습니다. 모니터링할 서비스의 하위 집합을 정의해야 합니다.

참고: 일부 서비스는 프로브를 지원하지 않으며 컨테이너 시작에 실패할 수 있습니다.

프로브를 사용하여 컨테이너를 확인하는 사전 정의된 방법에는 4가지가 있습니다. 각 프로브에서 다음 4가지 메커니즘 중 하나를 정확히 정의해야 합니다.

• exec - 컨테이너 내에서 지정된 명령어를 실행합니다. 종료 상태 코드가 0이면 실행이 성공한 것으로 간주됩니다.
• grpc - `gRPC`를 사용하여 리모트 프로시져 콜을 수행합니다. `gRPC` 프로브는 알파 기능입니다.
• httpGet - 지정된 포트 및 경로에서 포드의 IP 주소에 대해 HTTP GET 요청을 수행합니다. 상태 코드가 200에서 400 사이인 경우 요청이 성공한 것으로 간주됩니다.
• tcpSocket - 지정된 포트에서 포드의 IP 주소에 대해 TCP 확인을 수행합니다. 포트가 열려 있는 경우 진단이 성공한 것으로 간주됩니다.

기본적으로 마이그레이션 계획은 exec 프로빙 메서드를 사용 설정합니다. 마이그레이션 계획에 수동 구성을 사용하여 다른 방법을 사용 설정하세요.

준비 프로브의 외부 종속 항목을 추가하려면 기본 활성 프로브를 사용하는 동안 실행 준비 프로브와 로직을 구현하는 스크립트를 정의합니다.

다음 단계

• 마이그레이션 실행 방법 알아보기