Utiliser des contraintes liées aux règles de coût et de fiabilité
Policy Controller est fourni avec une bibliothèque par défaut de modèles de contraintes qui peuvent être utilisés avec le groupe de règles de coût et de fiabilité, qui permet d'adopter les bonnes pratiques pour exécuter des clusters GKE économiques sans compromettre les performances ou la fiabilité de leurs charges de travail.
Contraintes du groupe de règles relatives aux coûts et à la fiabilité
Nom de la contrainte | Description de la contrainte |
---|---|
cost-reliability-v2023-pod-disruption-budget | Nécessite une configuration de PodDisruptionBudget pour les déploiements, les ReplicaSets, les StatefulSets et les ReplicationController. |
cost-reliability-v2023-pod-resources-best-practices | Nécessite que les conteneurs définissent des demandes de ressources et respectent les bonnes pratiques. |
cost-reliability-v2023-required-labels | Tous les pods et contrôleurs (ReplicaSet, Deployment, StatefulSet et DaemonSet) doivent disposer des étiquettes d'environnement, d'équipe et d'application. |
cost-reliability-v2023-restrict-repos | Limite les images de conteneurs à une liste de dépôts autorisés afin d'utiliser Artifact Registry pour bénéficier du streaming d'images. |
cost-reliability-v2023-spotvm-termination-grace | La valeur terminationGracePeriodSeconds doit être inférieure ou égale à 15 s pour les pods et les modèles de pod avec nodeSelector ou nodeAfffinty pour gke-spot. |
Avant de commencer
- Installez et initialisez la Google Cloud CLI, qui fournit les commandes
gcloud
etkubectl
utilisées dans ces instructions. Si vous utilisez Cloud Shell, Google Cloud CLI est préinstallé. - Installez Policy Controller 1.15.3 ou version ultérieure sur votre cluster avec la bibliothèque par défaut de modèles de contraintes. Vous devez également activer la prise en charge des contraintes référentielles, car ce bundle contient des contraintes référentielles.
Configurer Policy Controller pour les contraintes référentielles
Enregistrez le fichier manifeste YAML suivant dans un fichier sous le nom
policycontroller-config.yaml
. Le fichier manifeste configure Policy Controller pour surveiller des types d'objets spécifiques.apiVersion: config.gatekeeper.sh/v1alpha1 kind: Config metadata: name: config namespace: "gatekeeper-system" spec: sync: syncOnly: - group: "" version: "v1" kind: "Service" - group: "policy" version: "v1" kind: "PodDisruptionBudget"
Appliquez le fichier manifeste
policycontroller-config.yaml
:kubectl apply -f policycontroller-config.yaml
Configurer le cluster et la charge de travail
- Tout
pod
sélectionné par unservice
doit inclure des vérifications d'aptitude. - Tous les éléments
deployment
,replicaset
,statefulset
etreplicationcontroller
doivent inclure un élémentpoddisruptionbudget
. - Tous les conteneurs doivent inclure les requêtes
cpu
etmemory
, et la limitememory
doit correspondre au nombre de requêtesmemory
, conformément aux bonnes pratiques. - Ajoutez les étiquettes
environment
,team
etapp
à tous les pods et modèles de pod. - Hébergez des images de conteneurs à l'aide d'Artifact Registry dans la même région que votre cluster pour activer le streaming d'images.
Autorisez Artifact Registry approprié en suivant l'exemple dans
cost-reliability-v2023-restrict-repos
. - Tous les pods et modèles de pod utilisant
gke-spot
doivent inclure unterminationGracePeriodSeconds
de 15 secondes ou moins.
Groupe de règles sur les coûts d'audit et la fiabilité
Policy Controller vous permet d'appliquer des règles à votre cluster Kubernetes. Pour tester vos charges de travail et leur conformité vis-à-vis des règles de coût et de fiabilité décrites dans le tableau précédent, vous pouvez déployer ces contraintes en mode "audit" pour détecter les cas de non-respect des règles et, surtout, vous permettre de les corriger avant de les appliquer à votre cluster Kubernetes.
Vous pouvez appliquer ces règles avec un paramètre spec.enforcementAction
défini sur dryrun
à l'aide de kubectl, kpt ou Config Sync.
kubectl
(Facultatif) Prévisualisez les contraintes de la règle avec kubectl:
kubectl kustomize https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/cost-reliability-v2023
Appliquez les contraintes de règle avec kubectl:
kubectl apply -k https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/cost-reliability-v2023
Le résultat est le suivant :
gkespotvmterminationgrace.constraints.gatekeeper.sh/cost-reliability-v2023-spotvm-termination-grace created k8sallowedrepos.constraints.gatekeeper.sh/cost-reliability-v2023-restrict-repos created k8spoddisruptionbudget.constraints.gatekeeper.sh/cost-reliability-v2023-pod-disruption-budget created k8spodresourcesbestpractices.constraints.gatekeeper.sh/cost-reliability-v2023-pod-resources-best-practices created k8srequiredlabels.constraints.gatekeeper.sh/cost-reliability-v2023-required-labels created
Vérifiez que les contraintes de règles ont été installées et si des cas de non-respect existent dans le cluster :
kubectl get constraints -l policycontroller.gke.io/bundleName=cost-reliability-v2023
Le résultat ressemble à ce qui suit :
NAME ENFORCEMENT-ACTION TOTAL-VIOLATIONS gkespotvmterminationgrace.constraints.gatekeeper.sh/cost-reliability-v2023-spotvm-termination-grace dryrun 0 NAME ENFORCEMENT-ACTION TOTAL-VIOLATIONS k8spodresourcesbestpractices.constraints.gatekeeper.sh/cost-reliability-v2023-pod-resources-best-practices dryrun 0 NAME ENFORCEMENT-ACTION TOTAL-VIOLATIONS k8spoddisruptionbudget.constraints.gatekeeper.sh/cost-reliability-v2023-pod-disruption-budget dryrun 0 NAME ENFORCEMENT-ACTION TOTAL-VIOLATIONS k8sallowedrepos.constraints.gatekeeper.sh/cost-reliability-v2023-restrict-repos dryrun 0 NAME ENFORCEMENT-ACTION TOTAL-VIOLATIONS k8srequiredlabels.constraints.gatekeeper.sh/cost-reliability-v2023-required-labels dryrun 0
kpt
Installez et configurez kpt.
kpt est utilisé dans ces instructions pour personnaliser et déployer des ressources Kubernetes.
Téléchargez le groupe de règles PCI-DSS v3.2.1 depuis GitHub à l'aide de Kpt:
kpt pkg get https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/cost-reliability-v2023
Exécutez la fonction kpt
set-enforcement-action
pour définir la mesure coercitive des règles surdryrun
:kpt fn eval cost-reliability-v2023 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 \ -- enforcementAction=dryrun
Initialisez le répertoire de travail avec kpt, qui crée une ressource pour suivre les modifications :
cd cost-reliability-v2023 kpt live init
Appliquez les contraintes de règles avec kpt :
kpt live apply
Vérifiez que les contraintes de règles ont été installées et si des cas de non-respect existent dans le cluster :
kpt live status --output table --poll-until current
L'état
CURRENT
confirme l'installation des contraintes.
Config Sync
Installez et configurez kpt.
kpt est utilisé dans ces instructions pour personnaliser et déployer des ressources Kubernetes.
Les opérateurs qui utilisent Config Sync pour déployer des règles sur leurs clusters peuvent suivre ces instructions :
Accédez au répertoire de synchronisation pour Config Sync :
cd SYNC_ROOT_DIR
Pour créer ou ajouter
.gitignore
avecresourcegroup.yaml
:echo resourcegroup.yaml >> .gitignore
Créez un répertoire
policies
dédié:mkdir -p policies
Téléchargez le lot de règles de coût et de fiabilité à partir de GitHub à l'aide de kpt:
kpt pkg get https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/cost-reliability-v2023 policies/cost-reliability-v2023
Exécutez la fonction kpt
set-enforcement-action
pour définir la mesure coercitive des règles surdryrun
:kpt fn eval policies/cost-reliability-v2023 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=dryrun
(Facultatif) Prévisualisez les contraintes de règle à créer:
kpt live init policies/cost-reliability-v2023 kpt live apply --dry-run policies/cost-reliability-v2023
Si votre répertoire de synchronisation pour Config Sync utilise Kustomize, ajoutez
policies/cost-reliability-v2023
à votrekustomization.yaml
racine. Sinon, supprimez le fichierpolicies/cost-reliability-v2023/kustomization.yaml
:rm SYNC_ROOT_DIR/policies/cost-reliability-v2023/kustomization.yaml
Transférez les modifications au dépôt Config Sync :
git add SYNC_ROOT_DIR/policies/cost-reliability-v2023 git commit -m 'Adding Cost and Reliability policy audit enforcement' git push
Vérifiez l'état de l'installation :
watch gcloud beta container fleet config-management status --project PROJECT_ID
L'état
SYNCED
confirme l'installation des règles .
Consulter les notifications de non-respect des règles
Une fois les contraintes des règles installées en mode audit, vous pouvez afficher les violations du cluster dans l'interface utilisateur à l'aide du tableau de bord Policy Controller.
Vous pouvez également utiliser kubectl
pour afficher les cas de non-respect sur le cluster à l'aide de la commande suivante:
kubectl get constraint -l policycontroller.gke.io/bundleName=cost-reliability-v2023 -o json | jq -cC '.items[]| [.metadata.name,.status.totalViolations]'
En cas de non-respect des règles, vous pouvez afficher la liste des messages de violation par contrainte à l'aide de la commande suivante:
kubectl get constraint -l policycontroller.gke.io/bundleName=cost-reliability-v2023 -o json | jq -C '.items[]| select(.status.totalViolations>0)| [.metadata.name,.status.violations[]?]'
Modification d'une mesure coercitive de groupe de règles sur les coûts et la fiabilité
Une fois que vous avez examiné les cas de non-respect des règles sur votre cluster, vous pouvez modifier le mode d'application afin que le contrôleur d'admission active warn
ou deny
bloque l'application des ressources non conformes au cluster.
kubectl
Utilisez kubectl pour définir l'action coercitive de la règle sur
warn
:kubectl get constraints -l policycontroller.gke.io/bundleName=cost-reliability-v2023 -o name | xargs -I {} kubectl patch {} --type='json' -p='[{"op":"replace","path":"/spec/enforcementAction","value":"warn"}]'
Vérifiez que la mesure coercitive des contraintes de règle a été mise à jour:
kubectl get constraints -l policycontroller.gke.io/bundleName=cost-reliability-v2023
kpt
Exécutez la fonction kpt
set-enforcement-action
pour définir la mesure coercitive des règles surwarn
:kpt fn eval -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=warn
Appliquez les contraintes de règles :
kpt live apply
Config Sync
Les opérateurs qui utilisent Config Sync pour déployer des règles sur leurs clusters peuvent suivre ces instructions :
Accédez au répertoire de synchronisation pour Config Sync :
cd SYNC_ROOT_DIR
Exécutez la fonction kpt
set-enforcement-action
pour définir la mesure coercitive des règles surwarn
:kpt fn eval policies/cost-reliability-v2023 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=warn
Transférez les modifications au dépôt Config Sync :
git add SYNC_ROOT_DIR/policies/cost-reliability-v2023 git commit -m 'Adding Cost and Reliability policy bundle warn enforcement' git push
Vérifiez l'état de l'installation :
gcloud alpha anthos config sync repo list --project PROJECT_ID
Votre dépôt qui s'affiche dans la colonne
SYNCED
confirme l'installation des règles.
Tester l'application des règles
Créez une ressource non conforme sur le cluster à l'aide de la commande suivante :
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
namespace: default
name: wp-non-compliant
labels:
app: wordpress
spec:
containers:
- image: wordpress
name: wordpress
ports:
- containerPort: 80
hostPort: 80
name: wordpress
EOF
Le contrôleur d'admission doit générer un avertissement indiquant les cas de non-respect des règles enfreints par cette ressource, comme illustré dans l'exemple suivant:
Warning: [cost-reliability-v2023-pod-resources-best-practices] Container <wordpress> must set <cpu> request. Warning: [cost-reliability-v2023-pod-resources-best-practices] Container <wordpress> must set <memory> request. Warning: [cost-reliability-v2023-required-labels] This app is missing one or more required labels: `environment`, `team`, and `app`. Warning: [cost-reliability-v2023-restrict-repos] container <wordpress> has an invalid image repo <wordpress>, allowed repos are ["gcr.io/gke-release/", "gcr.io/anthos-baremetal-release/", "gcr.io/config-management-release/", "gcr.io/kubebuilder/", "gcr.io/gkeconnect/", "gke.gcr.io/"] pod/wp-non-compliant created
Supprimer le groupe de règles relatives aux coûts et à la fiabilité
Si nécessaire, le lot de règles relatives aux coûts et à la fiabilité peut être supprimé du cluster.
kubectl
Utilisez kubectl pour supprimer les règles:
kubectl delete constraint -l policycontroller.gke.io/bundleName=cost-reliability-v2023
kpt
Supprimez les règles:
kpt live destroy
Config Sync
Les opérateurs qui utilisent Config Sync pour déployer des règles sur leurs clusters peuvent suivre ces instructions :
Transférez les modifications au dépôt Config Sync :
git rm -r SYNC_ROOT_DIR/policies/cost-reliability-v2023 git commit -m 'Removing Cost and Reliability policies' git push
Vérifiez l'état:
gcloud alpha anthos config sync repo list --project PROJECT_ID
Le dépôt qui s'affiche dans la colonne
SYNCED
confirme la suppression des règles.