Cette page décrit les actions de connectivité de sortie que vous devez effectuer sur une machine virtuelle (VM) ou un pod dans un projet pour permettre aux charges de travail de sortir de l'organisation. La procédure montre comment ajouter un libellé requis aux déploiements pour activer explicitement le trafic sortant et permettre aux charges de travail de communiquer en dehors de l'organisation.
Par défaut, Google Distributed Cloud (GDC) sous air gap empêche les charges de travail d'un projet de sortir de l'organisation. Les charges de travail peuvent quitter l'organisation si votre administrateur de plate-forme (AP) a désactivé la protection contre l'exfiltration de données pour le projet. En plus de désactiver la protection contre l'exfiltration de données, l'opérateur d'application (AO) doit ajouter le libellé egress.networking.gke.io/enabled: true
à la charge de travail du pod pour activer la connectivité de sortie pour ce pod. Lorsque vous attribuez et utilisez une adresse IP connue pour le projet, une traduction d'adresse réseau source (NAT) est effectuée sur le trafic sortant de l'organisation.
Vous pouvez gérer la connectivité de sortie des charges de travail dans un pod ou une VM.
Gérer le trafic sortant des charges de travail dans un pod
Pour configurer les charges de travail d'un pod pour la connectivité de sortie, vous devez d'abord vous assurer que la protection contre l'exfiltration de données est désactivée pour le projet. Assurez-vous ensuite que le libellé egress.networking.gke.io/enabled: true
est ajouté au pod. Si vous utilisez un constructeur de niveau supérieur, tel que Deployment
ou Daemonset
, pour gérer des ensembles de pods, vous devez configurer le libellé de pod dans ces spécifications.
L'exemple suivant montre comment créer un Deployment
à partir de son fichier manifeste. L'exemple de fichier contient la valeur egress.networking.gke.io/enabled: true
dans le champ labels
pour activer explicitement le trafic sortant du projet. Cette étiquette est ajoutée à chaque pod du déploiement et permet aux charges de travail des pods de quitter l'organisation.
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: DEPLOYMENT_NAME
spec:
replicas: NUMBER_OF_REPLICAS
selector:
matchLabels:
run: APP_NAME
template:
metadata:
labels: # The labels given to each pod in the deployment, which are used
# to manage all pods in the deployment.
run: APP_NAME
egress.networking.gke.io/enabled: true
spec: # The pod specification, which defines how each pod runs in the deployment.
containers:
- name: CONTAINER_NAME
image: CONTAINER_IMAGE
EOF
Remplacez les éléments suivants :
USER_CLUSTER_KUBECONFIG
: fichier kubeconfig du cluster d'utilisateur sur lequel vous déployez des charges de travail de conteneur.DEPLOYMENT_NAME
: fichier kubeconfig du cluster d'utilisateur sur lequel vous déployez des charges de travail de conteneur.APP_NAME
: nom de l'application à exécuter dans le déploiement.NUMBER_OF_REPLICAS
: nombre d'objetsPod
répliqués gérés par le déploiement.CONTAINER_NAME
: nom du conteneur.CONTAINER_IMAGE
: nom de l'image du conteneur. Vous devez inclure le chemin d'accès au registre de conteneurs et la version de l'image, par exempleREGISTRY_PATH/hello-app:1.0
.
Exemple :
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
run: my-app
template:
metadata:
labels:
run: my-app
egress.networking.gke.io/enabled: true
spec:
containers:
- name: hello-app
image: REGISTRY_PATH/hello-app:1.0
Gérer le trafic sortant des charges de travail dans une VM
Pour configurer des charges de travail dans une VM pour la connectivité de sortie, vous pouvez utiliser la console GDC pour la configuration de la VM ou créer une ressource VirtualMachineExternalAccess
. Pour savoir comment activer l'accès externe à une VM pour le transfert de données, consultez Activer l'accès externe dans la section Se connecter à des VM.