anthos-gke aws management init 및 anthos-gke aws management apply를 다시 실행하여 관리형 서비스에 변경사항을 적용합니다.
사용자 클러스터의 프록시 변경
사용자 클러스터를 만들 때 관리형 서비스의 프록시 설정이 사용됩니다.
관리형 서비스의 프록시 설정을 변경하지 않으면서 사용자 클러스터의 프록시 설정을 변경하려면 프록시 정보가 포함된 Kubernetes 보안 비밀을 만든 후 kubectl을 사용하여 변경사항을 적용해야 합니다.
Kubernetes 보안 비밀 만들기
먼저 보안 비밀을 설명하는 다음 콘텐츠가 포함된 YAML 파일을 만듭니다.
보안 비밀은 불투명 및 변경 불가능한 것으로 정의해야 합니다. 이 예시에서는 파일 이름 proxy-secret.yaml을 사용합니다.
apiVersion: v1
kind: Secret
metadata:
name: PROXY_SECRET
type: Opaque
immutable: true
stringData:
# You can include additional key value pairs as you do with Opaque Secrets
httpProxy: HTTP_PROXY
httpsProxy: HTTPS_PROXY
noProxy: NO_PROXY_LIST
다음과 같이 바꿉니다.
HTTP_PROXY를 HTTP 요청을 라우팅할 프록시 서버 주소로 변경합니다.
HTTPS_PROXY를 HTTPS 요청을 라우팅할 선택적 프록시 서버 주소로 변경합니다.
NO_PROXY_LIST를 프록시가 사용되어서는 안 되는 VPN 내의 IP, CIDR 범위 및 도메인에 대한 선택적 목록으로 변경합니다.
kubectl apply 명령어를 실행하여 새 프록시 설정을 적용하면 사용자 클러스터 상태가 Provisioned에서 Updating으로 변경된 다음 완료되면 Provisioned로 돌아갑니다.
두 개 이상의 사용자 클러스터에 대한 프록시 설정
사용자 클러스터가 여러 개이고 클러스터마다 서로 다른 프록시를 구성하려면 클러스터별로 사용자 클러스터의 프록시 변경에 나와 있는 안내를 따릅니다. 각 프록시에 대해 서로 다른 Kubernetes 보안 비밀을 만들어야 하며 해당 사용자 클러스터의 보안 비밀 이름을 참조하도록 각 사용자 클러스터 구성을 별도로 업데이트해야 합니다.
사용자 클러스터의 프록시 순환
이미 개별 프록시 설정이 있는 클러스터의 프록시 설정을 변경하려면 새 프록시 설정과 다른 보안 비밀 이름으로 새 보안 비밀을 만들고 적용합니다. 현재 보안 비밀 이름을 다시 사용할 경우 클러스터의 프록시 설정이 변경되지 않습니다.
문제 해결
보안 비밀이 올바른 형식이 아니거나 필수 키가 누락되면 명령어가 실패하고 변경사항이 적용되지 않습니다. 보안 비밀이 올바르게 검증되었는지 확인하려면 다음 명령어를 사용하여 AWSCluster 및 AWSNodePool의 Kubernetes 이벤트 로그를 확인합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-29(UTC)"],[],[],null,["# Changing Cluster Proxy Settings\n\nVersion 1.8 of GKE on AWS adds the ability to modify a cluster's proxy\nsettings without recreating a cluster.\n\nChanging the proxy for your management service\n----------------------------------------------\n\nTo modify proxy settings for your GKE on AWS management service,\nperform the following steps:\n\n1. Update the contents of the management service's proxy.json file, as described in\n [Creating the Proxy Config JSON File](/kubernetes-engine/multi-cloud/docs/aws/previous-generation/how-to/using-a-proxy#creating_the_proxy_configuration_json_file).\n\n2. Re-run `anthos-gke aws management init` and `anthos-gke aws management apply`\n to apply your changes to the management service.\n\nChanging the proxy for your user cluster\n----------------------------------------\n\n| **Note:** If you have several clusters and create a specific proxy for one of them, you must create a proxy for each of them. All user clusters can specify the same proxy.\n\nWhen you create a user cluster, it uses the management service's proxy settings.\nTo change the proxy settings for a user cluster without changing those\nof the management service, you must create a Kubernetes Secret\ncontaining the proxy information, then use `kubectl` to apply the changes.\n\n### Create a Kubernetes Secret\n\n1. First, create a YAML file with the following contents to describe the Secret.\n The Secret must be defined as opaque and immutable. This example uses the file\n name `proxy-secret.yaml`.\n\n \u003cbr /\u003e\n\n ```\n apiVersion: v1\n kind: Secret\n metadata:\n name: PROXY_SECRET\n type: Opaque\n immutable: true\n stringData:\n # You can include additional key value pairs as you do with Opaque Secrets\n httpProxy: HTTP_PROXY\n httpsProxy: HTTPS_PROXY\n noProxy: NO_PROXY_LIST\n \n ```\n\n \u003cbr /\u003e\n\n Replace:\n - \u003cvar translate=\"no\"\u003eHTTP_PROXY\u003c/var\u003e with the proxy server address to route HTTP requests through\n - \u003cvar translate=\"no\"\u003eHTTPS_PROXY\u003c/var\u003e with an optional proxy server address to route HTTPS requests through\n - \u003cvar translate=\"no\"\u003eNO_PROXY_LIST\u003c/var\u003e with an optional list of IPs, CIDR ranges, and domains within your VPN for which a proxy should not be used\n - \u003cvar translate=\"no\"\u003ePROXY_SECRET\u003c/var\u003e with the name you choose for the Secret\n2. Apply your changes to create the Secret:\n\n env HTTPS_PROXY=http://localhost:8118 \\\n kubectl apply -f ./proxy-secret.yaml\n\n### Update the user cluster and node pool configs\n\nNext, update the AWSCluster and AWSNodePool\nconfiguration to refer to the Secret name under `spec.proxySecretName` and\n`spec.controlPlane.proxySecretName` respectively.\n\nFinally, issue the following command to update your user cluster. \n\n env HTTPS_PROXY=http://localhost:8118 \\\n kubectl apply -f \u003cvar translate=\"no\"\u003eCLUSTER_YAML_FILE\u003c/var\u003e\n\nReplace \u003cvar translate=\"no\"\u003eCLUSTER_YAML_FILE\u003c/var\u003e with the name of the yaml file that defines\nyour cluster.\n\n### User cluster status changes\n\nAfter you run the `kubectl apply` command to apply the new proxy settings,\nthe user cluster status will change from `Provisioned` to `Updating`, then\nreturn to `Provisioned` when done.\n\nSetting proxies for more than one user cluster\n----------------------------------------------\n\nIf you have several user clusters and want to configure different proxies\nfor each of them, follow the [Changing the proxy for your user cluster](#changing-user-cluster-proxy)\ninstructions for each of your clusters. You must create a different Kubernetes\nSecret for each proxy, and must update each user cluster config separately to\nrefer to the name of the Secret for that user cluster.\n\nRotating proxies for a user cluster\n-----------------------------------\n\nTo change the proxy settings for a cluster that already has\nindividual proxy settings, create and apply a new Secret with the new proxy\nsettings and a different Secret name. If you reuse the current Secret name, the\ncluster's proxy settings will not be changed.\n\nTroubleshooting\n---------------\n\nIf the Secret is not well-formed or is missing required keys, the command\nfails and the change isn't applied. To check if your Secret was\ncorrectly validated, look at the Kubernetes Event log for AWSClusters\nand AWSNodePools with the following command: \n\n env HTTPS_PROXY=http://localhost:8118 \\\n kubectl get events\n\nIf there was an error in your Secret configuration, delete the\nSecret with the following command:\n\n\u003cbr /\u003e\n\n```\n env HTTPS_PROXY=http://localhost:8118 \\\n kubectl delete secret SECRET_NAME\n \n```\n\n\u003cbr /\u003e\n\nReplace \u003cvar translate=\"no\"\u003eSECRET_NAME\u003c/var\u003e with the name of your Secret.\n\nThen re-create the Secret with a correctly-formatted proxy Secret YAML file\nand re-apply the change. You can use the same Secret name as was used in the\nfirst attempt.\n\nFor more information\n--------------------\n\nTo configure proxy settings for the first time, see [Using a proxy](/kubernetes-engine/multi-cloud/docs/aws/previous-generation/how-to/using-a-proxy).\n\nTo create a dedicated AWS VPC, see [Installing the management service](/kubernetes-engine/multi-cloud/docs/aws/previous-generation/how-to/installing-management)."]]
