Linux VM의 마이그레이션 계획 맞춤설정
마이그레이션 계획을 실행하기 전에 이를 검토하고 선택적으로 맞춤설정해야 합니다. 마이그레이션 계획의 세부정보는 소스 VM에서 워크로드 컨테이너 아티팩트를 추출하고 컨테이너 이미지를 프로덕션 클러스터와 같은 다른 클러스터에 배포하는 데 사용할 수 있는 Kubernetes 배포 파일을 생성하는 데 사용됩니다.
이 섹션에서는 마이그레이션을 실행하고 배포 아티팩트를 생성하기 전에 고려할 수 있는 마이그레이션 계획의 콘텐츠와 종류를 설명합니다.
시작하기 전에
이 주제에서는 사용자가 이미 마이그레이션을 만들었고 해당 마이그레이션 계획 파일이 있다고 가정합니다.
마이그레이션 계획 수정
migctl 도구나 Google Cloud Console을 사용하여 마이그레이션 계획을 수정할 수 있습니다.
migctl
수정하려면 먼저 마이그레이션 계획을 다운로드해야 합니다.
마이그레이션 계획을 다운로드합니다. Linux 워크로드의 마이그레이션 계획은 LinuxMigrationCommonSpec으로 표시됩니다.
migctl migration get my-migration
다운로드한 마이그레이션 계획
my-migration.yaml을 텍스트 편집기에서 수정합니다.수정이 완료되면 수정된 마이그레이션 계획을 저장하고 업로드합니다.
migctl migration update my-migration --main-config my-migration.yaml
추가 수정이 필요하면 이 단계를 반복합니다.
콘솔
YAML 편집기를 사용하여 Google Cloud Console에서 마이그레이션 계획을 수정합니다. Linux 워크로드의 마이그레이션 계획은 LinuxMigrationCommonSpec CRD로 표시됩니다.
Google Cloud 콘솔에서 Migrate to Containers 페이지를 엽니다.
마이그레이션 탭을 클릭하여 사용 가능한 마이그레이션이 포함된 테이블을 표시합니다.
원하는 마이그레이션 행에서 마이그레이션 이름을 선택하여 세부정보 탭을 엽니다.
YAML 탭을 선택합니다.
필요에 따라 마이그레이션 계획을 수정합니다.
수정이 완료되면 다음을 수행할 수 있습니다.
마이그레이션 계획을 저장합니다. 그런 다음 마이그레이션을 수동으로 실행하여 마이그레이션 아티팩트를 생성해야 합니다. 마이그레이션 실행에 표시된 절차를 사용합니다.
아티팩트를 저장 및 생성합니다. 수정 사항을 사용해서 마이그레이션을 실행하여 마이그레이션 아티팩트를 생성합니다. 프로세스는 마이그레이션 실행에 설명된 것과 동일합니다. 그런 후 마이그레이션 모니터링에 설명된 대로 마이그레이션을 모니터링할 수 있습니다.
CRD
마이그레이션 계획을 다운로드하여 수정한 다음 적용해야 합니다. Linux 워크로드의 마이그레이션 계획은 LinuxMigrationCommonSpec CRD로 표시됩니다.
AppXGenerateArtifactsFlow이름을 가져옵니다.kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system -o jsonpath={.status.migrationPlanRef.name} my-migration이름 지정 패턴은
appx-generateartifactsflow-id형식으로 반환됩니다.이름을 기준으로 마이그레이션 계획을 가져오고
my-plan.yaml파일에 기록합니다.kubectl -n v2k-system get appxgenerateartifactsflows.anthos-migrate.cloud.google.com -o jsonpath={.spec.appXGenerateArtifactsConfig} appx-generateartifactsflow-id > my-plan.yaml필요에 따라 마이그레이션 계획을 수정합니다.
파일을 적용합니다.
kubectl patch appxgenerateartifactsflows.anthos-migrate.cloud.google.com --type merge -n v2k-system --patch '{"spec": {"appXGenerateArtifactsConfig": '"$(jq -n --rawfile plan my-plan.yaml '$plan')"'}}' appx-generateartifactsflow-id
마이그레이션에서 제외할 콘텐츠 지정
기본적으로 Migrate to Containers는 GKE 컨텍스트와 관련이 없는 일반적인 VM 콘텐츠를 제외합니다. 이 필터를 맞춤설정할 수 있습니다.
filters 필드 값은 마이그레이션에서 제외되어야 하며 컨테이너 이미지의 일부가 아닌 경로를 나열합니다.
필드의 값은 전송할 파일과 건너뛸 파일을 지정하는 rsync 필터 규칙을 나열합니다. 각 경로 및 파일 앞에 마이너스 기호가 있으면 목록의 항목을 마이그레이션에서 제외하도록 지정됩니다. 이 목록은 YAML의 행 순서에 따라 처리되며 이에 따라 제외/포함이 평가됩니다.
자세한 내용은 rsync manpage의 패턴 규칙 포함/제외 섹션을 참조하세요.
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 필드 값은 마이그레이션된 VM에서 만든 두 이미지의 이름과 위치를 정의합니다. 다른 이름을 사용하려는 경우 이 값을 변경할 수 있습니다.
마이그레이션하는 동안 Migrate to Containers는 마이그레이션 워크로드를 나타내는 파일 및 디렉터리를 기본적으로 마이그레이션 중에 사용할 Container Registry에 복사합니다. 마이그레이션 프로세스는 추출된 워크로드를 GKE에서 실행할 수 있는 이미지에 맞게 조정합니다.
Migrate to Containers는 레지스트리의 원본 VM(base 경로)에서 파일과 디렉터리를 보존합니다. 이 이미지는 추출된 워크로드 파일을 포함하는 실행 불가능한 기본 레이어의 기능을 수행하며, 이는 Migrate to Containers 런타임 소프트웨어 레이어와 결합되어 실행 가능한 컨테이너 이미지를 구축합니다.
별도의 레이어를 사용하면 필요에 따라 기본 레이어나 Migrate to Containers 소프트웨어 레이어를 별도로 업데이트하여 이후 컨테이너 이미지의 업데이트가 간소화됩니다.
이 이미지는 실행할 수 없지만 Migrate to Containers를 업그레이드 할 때 Migrate to Containers가 원본 이미지에서 컨테이너를 업데이트할 수 있습니다.
base 및 name 필드 값은 레지스트리에서 만든 이미지를 지정합니다.
base-- 소스 플랫폼에서 복사된 VM 파일 및 디렉터리에서 생성된 이미지의 이름입니다. 이 이미지는 GKE에서 배포할 수 있도록 조정되지 않았으므로 GKE에서 실행되지 않습니다.name-- 컨테이너에 사용되는 실행 가능한 이미지의 이름입니다. 이 이미지에는 소스 VM의 콘텐츠와 실행 가능한 Migrate to Containers 런타임이 모두 포함되어 있습니다.
image:
# Review and set the name for extracted non-runnable base image,
# if an image tag is not specified, a random tag is auto-generated when the image is built.
base: "centos-mini-non-runnable-base"
# Review and set the name for runnable container image,
# if an image tag is not specified, a random tag is auto-generated when the image is built.
name: "centos-mini"
기본적으로 마이그레이션의 타임스탬프에 해당하는 태그가 이러한 값에 자동으로 적용됩니다. 이 태그의 형식은 다음과 같습니다.
MM-DD-YYYY--hh:mm:ss
기본 태그를 재정의하여 자체 태그를 적용하려면 CRD를 수정하고 아래 표시된 것처럼 추가합니다.
image:
# Review and set the name for extracted non-runnable base image,
# if an image tag is not specified, a random tag is auto-generated when the image is built.
base: "centos-mini-non-runnable-base:tag"
# Review and set the name for runnable container image,
# if an image tag is not specified, a random tag is auto-generated when the image is built.
name: "centos-mini:tag"
서비스 목록 맞춤설정
기본적으로 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파일,deployment_spec.yaml파일, Dockerfile을 포함한 마이그레이션 아티팩트를 다시 생성합니다.
또는 마이그레이션 아티팩트를 생성하기 위해 마이그레이션을 실행한 후 blocklist.yaml 파일을 직접 편집한 다음 컨테이너 이미지를 다시 빌드하고 푸시할 수 있습니다. 예를 들면 다음과 같습니다.
blocklist.yaml파일을 업데이트합니다.컨테이너 이미지를 다시 빌드하고 푸시합니다.
컨테이너 이미지를 다시 빌드하고 푸시하는 방법은 빌드 환경에 따라 달라집니다. 이 옵션은 다음과 같습니다.
gcloud: 빠른 시작: 빌드의 설명에 따라 이미지를 다시 빌드하고 Container Registry에 푸시합니다.docker build: 이미지 빌드 및 실행을 참조하세요.
새 이미지를 다시 빌드하고 푸시한 후 편집기에서
deployment_spec.yaml파일을 열어 이미지 위치를 업데이트합니다.spec: containers: - image: new-image-location
예를 들어
gcloud를 사용하여 이미지를 다시 빌드하고 Container Registry에 푸시하면 new-image-location이my-new-image:v1.0일 수 있습니다.
서비스 엔드포인트 맞춤설정
마이그레이션 계획에는 마이그레이션된 워크로드에서 제공하는 Kubernetes 서비스를 만드는 데 사용되는 포트와 프로토콜을 정의하는 endpoints 배열이 포함됩니다.
엔드포인트 정의를 추가, 수정, 삭제하여 마이그레이션 계획을 맞춤설정할 수 있습니다.
각 서비스 엔드포인트에서 다음 정의를 마이그레이션 계획에 추가합니다.
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 마운트 지점 정의를 추가하거나 수정하여 마이그레이션 계획을 맞춤설정할 수 있습니다.
마이그레이션 계획을 생성할 때 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 정의를 만듭니다.
예를 들어 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가 소스 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의 해당 필드와 동일한 함수를 공유합니다.
- 활성 프로브 - 활성 프로브는 컨테이너를 다시 시작할 시점을 파악하는 데 사용됩니다.
- 준비 프로브 - 준비 프로브는 컨테이너가 트래픽을 수락할 준비가 된 시점을 파악하는 데 사용됩니다. 프로브가 성공한 경우에만 포드에 트래픽 전송을 시작하려면 준비 프로브를 지정합니다. 준비 프로브는 활성 프로브와 유사하게 작동할 수 있지만 이 사양의 준비 프로브에서는 포드가 트래픽을 수신하지 않고 시작하며 프로브가 성공한 후에만 트래픽을 수신하기 시작함을 나타냅니다.
검색 후에는 프로브 구성이 마이그레이션 계획에 추가됩니다. 프로브는 아래와 같이 기본 구성에서 사용할 수 있습니다. 프로브를 사용 중지하려면 yaml에서 probes 섹션을 삭제합니다.
v2kServiceManager: true
deployment:
probes:
livenessProbe:
exec:
command:
- gamma
- /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 프로빙 메서드를 사용 설정합니다. 마이그레이션 계획에 수동 구성을 사용하여 다른 방법을 사용 설정하세요.
준비 프로브의 외부 종속 항목을 추가하려면 기본 활성 프로브를 사용하는 동안 실행 준비 프로브와 로직을 구현하는 스크립트를 정의합니다.
다음 단계
- 마이그레이션 실행 방법 알아보기