|
Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi. |
|
Il s'agit d'une documentation non publiée pour Admission Controller 1.34-dev. |
Démarrage rapide du traçage
Cette section montre comment activer la prise en charge du traçage pour le Policy Server.
|
Avant de continuer, assurez-vous d’avoir complété la section précédente OpenTelemetry de cette documentation. C’est nécessaire pour que cette section fonctionne correctement. |
Le traçage vous permet de collecter des détails précis sur les évaluations de stratégies. Cela peut être un outil utile pour déboguer des problèmes dans votre SUSE Security Admission Controller déploiement et stratégies.
Vous utilisez Jaeger — qui sert à recevoir, stocker et visualiser les événements de traçage.
Installer Jaeger
Vous utilisez le Jaeger Operator pour gérer tous les différents composants de Jaeger. Vous pouvez installer le Jaeger Operator en utilisant des charts Helm.
|
Au moment de la rédaction (2022-06-21), seules des versions spécifiques de Jaeger sont compatibles avec Cert Manager, voir le tableau de compatibilité. |
Pour installer le chart Helm :
helm repo add jaegertracing https://jaegertracing.github.io/helm-charts
helm upgrade -i --wait \
--namespace jaeger \
--create-namespace \
--version 2.49.0 \
jaeger-operator jaegertracing/jaeger-operator \
--set rbac.clusterRole=true
|
Ceci est non adapté à un déploiement en production. Vous devriez consulter la documentation officielle de Jaeger. |
Pour créer une ressource Jaeger :
kubectl apply -f - <<EOF
apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
name: my-open-telemetry
namespace: jaeger
spec: {}
EOF
Après la création des ressources Jaeger Operator, vous avez un Service sous my-open-telemetry-collector.jaeger.svc.cluster.local. L’interface utilisateur de Jaeger Query est exposée par le Service my-open-telemetry-query dans l’espace de noms jaeger.
Installez Admission Controller
Vous pouvez maintenant procéder au déploiement de Admission Controller de la manière habituelle.
|
Le |
Comme première étape, vous ajoutez le dépôt Helm qui contient Admission Controller :
helm repo add kubewarden https://charts.kubewarden.io
Ensuite, vous installez les définitions de ressources personnalisées (CRDs) définies par Admission Controller :
helm install --wait \
--namespace kubewarden \
--create-namespace \
kubewarden-crds kubewarden/kubewarden-crds
Vous pouvez maintenant déployer le reste de la pile Admission Controller. Le chart Helm officiel kubewarden-defaults crée un PolicyServer nommé default. Vous souhaitez que cette instance de PolicyServer ait le traçage activé.
Pour ce faire, vous devez spécifier quelques valeurs supplémentaires pour le chart kubewarden-controller. Vous devez créer un fichier values.yaml avec le contenu suivant :
telemetry:
mode: sidecar
tracing: True
sidecar:
tracing:
jaeger:
endpoint: "my-open-telemetry-collector.jaeger.svc.cluster.local:4317"
tls:
insecure: true
|
Pour des raisons de simplicité, il n’y a pas de cryptage de la communication entre le collecteur OpenTelemetry et le point de terminaison Jaeger. Encore une fois, cela est non adapté à un déploiement en production. Consultez la documentation officielle de Jaeger. |
Ensuite, vous pouvez procéder à l’installation des charts Helm :
helm install --wait --namespace kubewarden --create-namespace \
--values values.yaml \
kubewarden-controller kubewarden/kubewarden-controller
helm install --wait --namespace kubewarden --create-namespace \
kubewarden-defaults kubewarden/kubewarden-defaults
Cela crée l’instance default de PolicyServer :
kubectl get policyservers.policies.kubewarden.io
NAME AGE
default 3m7s
En regardant de plus près le Pod exécutant l’instance de PolicyServer, vous pouvez voir qu’il a deux conteneurs à l’intérieur. Le policy-server et le collecteur OpenTelemetry sidecar otc-container.
Application d’une stratégie
Vous commencez par déployer la stratégie safe-labels.
Vous souhaitez que la stratégie soit appliquée uniquement dans les espaces de noms qui ont une étiquette environment avec une valeur de production.
À un espace de noms qui a une telle étiquette :
kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
name: team-alpha-prod
labels:
environment: production
EOF
Ensuite, vous pouvez définir une ClusterAdmissionPolicy :
kubectl apply -f - <<EOF
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
name: safe-labels
spec:
module: registry://ghcr.io/kubewarden/policies/safe-labels:v0.1.6
settings:
mandatory_labels:
- owner
rules:
- apiGroups:
- apps
apiVersions:
- v1
resources:
- deployments
operations:
- CREATE
- UPDATE
namespaceSelector:
matchExpressions:
- key: environment
operator: In
values: ["production"]
mutating: false
EOF
Vous devez attendre que la stratégie devienne active :
kubectl wait --for=condition=PolicyActive clusteradmissionpolicy/safe-labels
Une fois la stratégie active, vous pouvez l’essayer :
kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
namespace: team-alpha-prod
labels:
owner: octocat
spec:
selector:
matchLabels:
app: nginx
replicas: 0
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
EOF
La stratégie permet la création de cet objet Deployment car il ne viole pas la stratégie.
La stratégie bloque cet objet Deployment :
kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment-without-labels
namespace: team-alpha-prod
spec:
selector:
matchLabels:
app: nginx
replicas: 0
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
EOF
La stratégie n’est pas appliquée dans un autre espace de noms.
Cette commande crée un nouvel espace de noms appelé team-alpha-staging :
kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
name: team-alpha-staging
labels:
environment: staging
EOF
La stratégie permet la création d’une ressource Deployment, sans aucune étiquette, dans l’espace de noms team-alpha-staging :
kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment-without-labels
namespace: team-alpha-staging
spec:
selector:
matchLabels:
app: nginx
replicas: 0
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
EOF
Comme prévu, cette ressource est créée avec succès.
Exploration de l’interface utilisateur de Jaeger
Vous pouvez voir les événements de trace envoyés par l’instance PolicyServer à Jaeger, car il y a un nouveau service kubewarden-policy-server répertorié dans l’interface utilisateur :
Le collecteur Jaeger reçoit les traces générées par votre PolicyServer.
Si vous avez installé Traefik dans le guide précédent, exposez l’interface utilisateur de requête Jaeger avec ce Ingress :
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-open-telemetry-query
namespace: jaeger
spec:
ingressClassName: traefik
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-open-telemetry-query
port:
number: 16686
EOF
Pour accéder à l’interface utilisateur de Jaeger avec Traefik, exécutez :
kubectl -n traefik port-forward service/traefik 8080:80
Ensuite, allez à http://localhost:8080.
Si vous préférez contourner Traefik, accédez directement à Jaeger :
kubectl -n jaeger port-forward service/my-open-telemetry-query 16686
Ensuite, allez à http://localhost:16686.