Installation sur AWS EKS Fargate

New Relic prend en charge monitoring de la charge de travail Kubernetes sur EKS Fargate en injectant automatiquement un side-car contenant l'agent infrastructure et l'intégration nri-kubernetes dans chaque pod devant être monitoré.

Si le même cluster Kubernetes contient également des nœuds EC2, notre solution sera également affichée comme un DaemonSet dans chacun d'eux. Aucun side-car ne sera injecté dans le pod planifié dans les nœuds EC2, et aucun DaemonSet ne sera déployé sur les nœuds Fargate. Voici un exemple d'instance hybride avec des nœuds Fargate et EC2 :

New Relic collecte toutes les métriques prises en charge pour tous les objets Kubernetes, quel que soit l'endroit où ils sont planifiés, qu'il s'agisse de nœuds Fargate ou EC2. Veuillez noter qu'en raison des limitations imposées par Fargate, l'intégration de New Relic est limitée à l'exécution en mode non privilégié sur les nœuds Fargate. Cela signifie que les métriques qui sont généralement extraites directement de l'hôte, comme les processus en cours d'exécution, ne seront pas disponibles pour les nœuds Fargate.

Dans les deux scénarios, l'agent extraira les données de Kube State Métriques (KSM), Kubelet et cAdvisor et enverra les données dans le même format.

Les autres composants de la solution New Relic pour Kubernetes, tels que nri-prometheus, nri-metadata-injection et nri-kube-events, n'ont aucune particularité et seront déployés par notre Helm Chart normalement comme ils le feraient dans des environnements non Fargate.

Vous pouvez choisir entre deux alternatives pour installer l'observabilité complète de New Relic dans votre cluster EKS Fargate :

• injection automatique (recommandée)
• injectionmanuelle

Quelle que soit l’approche choisie, l’expérience est exactement la même après son installation. La seule différence réside dans la manière dont le conteneur est injecté. Nous vous recommandons de configurer automatique injection avec l'opérateur monitoring d' de New Relicinfrastructure car cela éliminera le besoin de modifier manuellement chaque déploiement que vous souhaitez monitorer.

injection automatique (recommandée)

Par défaut, lorsque la prise en charge de Fargate est activée, New Relic déploiera un opérateur sur le cluster (newrelic-infra-operator). Une fois déployé, cet opérateur injectera automatiquement le sidecar monitoring dans les pods programmés dans les nœuds Fargate, tout en gérant également la création et la mise à jour de Secrets, ClusterRoleBindings et de toute autre ressource associée.

Cet opérateur accepte une variété d'options configuration avancées qui peuvent être utilisées pour restreindre ou élargir la portée de l' injection, grâce à l'utilisation de sélecteurs d'étiquettes pour le pod et l'espace de nommage.

Ce que fait l'opérateur

Dans les coulisses, l'opérateur met en place un MutatingWebhookConfiguration, qui lui permet de modifier les objets pod qui sont sur le point d'être créés dans le cluster. Lors de cet événement, et lorsque le pod en cours de création correspond à la configuration de l'utilisateur, l'opérateur va :

1. Ajoutez un conteneur sidecar au pod contenant l’intégration New Relic Kubernetes.
2. Si un secret n'existe pas, créez-en un dans le même espace de nommage que le pod contenant New Relic clé de licence, qui est nécessaire pour que le side-car puisse signaler des données.
3. Ajoutez le compte de service du pod à un ClusterRoleBinding précédemment créé par le graphique de l'opérateur, ce qui accordera à ce side-car les autorisations requises pour atteindre le point de terminaison des métriques Kubernetes .

Le ClusterRoleBinding accorde les autorisations suivantes au pod en cours d'injection :

- apiGroups: [""]
  resources:
    - "nodes"
    - "nodes/metrics"
    - "nodes/stats"
    - "nodes/proxy"
    - "pods"
    - "services"
    - "namespaces"
  verbs: ["get", "list"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]

Voici le injection workflow:

$
helm repo add newrelic https://helm-charts.newrelic.com

## Global values

global:
# -- The cluster name for the Kubernetes cluster.
cluster: "_YOUR_K8S_CLUSTER_NAME_"

# -- The license key for your New Relic Account. This will be preferred configuration option if both `licenseKey` and `customSecret` are specified.
licenseKey: "_YOUR_NEW_RELIC_LICENSE_KEY_"

# -- (bool) In each integration it has different behavior. Enables operating system metric collection on each EC2 K8s node. Not applicable to Fargate nodes.
# @default -- false
privileged: true

# -- (bool) Must be set to `true` when deploying in an EKS Fargate environment
# @default -- false
fargate: true

## Enable nri-bundle sub-charts

newrelic-infra-operator:
# Deploys the infrastructure operator, which injects the monitoring sidecar into Fargate pods
enabled: true
tolerations: 
    - key: "eks.amazonaws.com/compute-type"
    operator: "Equal"
    value: "fargate"
    effect: "NoSchedule"
config:
    ignoreMutationErrors: true
    infraAgentInjection:
    # Injection policies can be defined here.  See [values file](https://github.com/newrelic/newrelic-infra-operator/blob/main/charts/newrelic-infra-operator/values.yaml#L114-L125) for more detail.
    policies:
    - namespaceName: namespace-a
    - namespaceName: namespace-b

newrelic-infrastructure:
# Deploys the Infrastructure Daemonset to EC2 nodes.  Disable for Fargate-only clusters.
enabled: true

nri-metadata-injection:
# Deploy our mutating admission webhook to link APM and Kubernetes entities
enabled: true

kube-state-metrics:
# Deploys Kube State Metrics.  Disable if you are already running KSM in your cluster.
enabled: true

nri-kube-events:
# Deploy the Kubernetes events integration.
enabled: true

newrelic-logging:
# Deploys the New Relic's Fluent Bit daemonset to EC2 nodes.  Disable for Fargate-only clusters.
enabled: true

newrelic-prometheus-agent:
# Deploys the Prometheus agent for scraping Prometheus endpoints.
enabled: true
config:
    kubernetes:
    integrations_filter:
        enabled: true
        source_labels: ["app.kubernetes.io/name", "app.newrelic.io/name", "k8s-app"]
        app_values: ["redis", "traefik", "calico", "nginx", "coredns", "kube-dns", "etcd", "cockroachdb", "velero", "harbor", "argocd", "istio"]

$
helm upgrade --install newrelic-bundle newrelic/nri-bundle -n newrelic --create-namespace -f values.yaml

injection automatique : les limites connues

Voici quelques points à prendre en compte lors de l’utilisation de l’injection automatique :

1. Actuellement, il n'existe aucun contrôleur qui monitore l'ensemble du cluster pour s'assurer que les secrets qui ne sont plus nécessaires sont collectés. Cependant, tous les objets partagent la même étiquette que vous pouvez utiliser pour supprimer toutes les ressources, si nécessaire. Nous injectons l’étiquette newrelic/infra-operator-created: true, que vous pouvez utiliser pour supprimer des ressources avec une seule commande.

2. Pour le moment, il n'est pas possible d'utiliser le sidecar injecté pour monitorer les services exécutés dans le pod. Le side-car monitorera uniquement Kubernetes lui-même. Cependant, un utilisateur avancé pourrait vouloir exclure ces pods de injection automatique et injecter manuellement une version personnalisée du side-car avec l'intégration sur hôte activée en les configurant et en montant leur configuration au bon endroit. Pour obtenir de l'aide, consultez ce tutoriel.

injection automatique : configuration

Vous pouvez configurer différents aspects de l'injection automatique. Par défaut, l'opérateur injectera le sidecar monitoring dans tous les pods déployés dans les nœuds Fargate qui ne font pas partie d'un Job ou d'un BatchJob.

Ce comportement peut être modifié via les options de configuration. Par exemple, vous pouvez définir des sélecteurs pour affiner ou élargir la sélection des pods injectés, affecter des ressources à l'opérateur et régler le side-car. Vous pouvez également ajouter d’autres attributs, étiquettes et variables d’environnement. Veuillez vous référer aux tableaux README.md et values.yaml.

Mettre à jour vers la dernière version ou vers une nouvelle configuration

Pour mettre à jour vers la dernière version de l'intégration EKS Fargate, mettez à niveau le référentiel Helm à l'aide de helm repo update newrelic et réinstallez le bundle en exécutant simplement à nouveau la commande ci-dessus.

Pour mettre à jour la configuration de l'agent infrastructure injecté ou de l'opérateur lui-même, modifiez le values-newrelic.yaml et mettez à niveau la sortie Helm avec la nouvelle configuration. L'opérateur est mis à jour immédiatement, et votre charge de travail sera instrumentée avec la nouvelle version lors de son prochain redémarrage. Si vous souhaitez les mettre à niveau immédiatement, vous pouvez forcer un redémarrage de votre charge de travail en exécutant :

$
kubectl rollout restart deployment YOUR_APP

injection automatique : Désinstaller

Afin de désinstaller le sidecar effectuant l'injection automatique mais de conserver le reste de la solution New Relic, à l'aide de Helm, désactivez l'opérateur infra en définissant infra-operator.enabled sur false, soit dans le fichier values.yaml soit dans la ligne de commande (--set), et réexécutez la commande d'installation ci-dessus.

Nous vous recommandons fortement de conserver l'indicateur --set global.fargate=true , car il n'active pas l'injection automatique mais rend les autres composants de l'installation sensibles à Fargate, empêchant ainsi tout comportement indésirable.

Pour désinstaller toute la solution :

1. Désinstallez complètement la sortie Helm .

2. Déroulez le pod afin de retirer le side-car :

   bash

   Copier

   $
   kubectl rollout restart deployment YOUR_APP

3. Ramassez les secrets :

   bash

   Copier

   $
   kubectl delete secrets -n YOUR_NAMESPACE -l newrelic/infra-operator-created=true

injectionmanuelle

Si vous avez des inquiétudes concernant l' injection automatique, vous pouvez injecter le side-car manuellement directement en modifiant les manifestes de la charge de travail planifiée qui va être planifiée sur les nœuds Fargate. Veuillez noter que l'ajout du sidecar dans le déploiement planifié dans les nœuds EC2 peut entraîner des données incorrectes ou dupliquées, en particulier si ces nœuds sont déjà monitorés avec le DaemonSet.

Ces objets sont requis pour que le side-car puisse signaler correctement les données :

• Le ClusterRole fournissant l'autorisation nécessaire à l'intégration nri-kubernetes .
• Un ClusterRoleBinding reliant le ClusterRole et le compte de service du pod.
• Le secret stockant New Relic licenseKey dans chaque espace de nommage Fargate.
• Le conteneur sidecar dans le modèle spécifique de la workload du moniteur.

Suivez ces étapes pour l'injection manuelle :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
    labels:
    app: newrelic-infrastructure
    name: newrelic-newrelic-infrastructure-infra-agent
rules:
    - apiGroups:
        - ""
    resources:
        - nodes
        - nodes/metrics
        - nodes/stats
        - nodes/proxy
        - pods
        - services
    verbs:
        - get
        - list
    - nonResourceURLs:
        - /metrics
    verbs:
        - get

apiVersion: apps/v1
kind: Deployment
spec:
    template:
    spec:
        containers:
        - name: newrelic-infrastructure
        env:
        - name: NRIA_LICENSE_KEY
            valueFrom:
            secretKeyRef:
                key: license
                name: newrelic-newrelic-infrastructure-config
        - name: NRIA_VERBOSE
            value: "1"
        - name: DISABLE_KUBE_STATE_METRICS
            value: "true"
        - name: CLUSTER_NAME
            value: testing-injection
        - name: COMPUTE_TYPE
            value: serverless
        - name: NRK8S_NODE_NAME
            valueFrom:
            fieldRef:
                apiVersion: v1
                fieldPath: spec.nodeName
        - name: NRIA_DISPLAY_NAME
            valueFrom:
            fieldRef:
                apiVersion: v1
                fieldPath: spec.nodeName
        - name: NRIA_CUSTOM_ATTRIBUTES
            value: '{"clusterName":"$(CLUSTER_NAME)", "computeType":"$(COMPUTE_TYPE)", "fargateProfile":"[YOUR FARGATE PROFILE]"}'
        - name: NRIA_PASSTHROUGH_ENVIRONMENT
            value: KUBERNETES_SERVICE_HOST,KUBERNETES_SERVICE_PORT,CLUSTER_NAME,CADVISOR_PORT,NRK8S_NODE_NAME,KUBE_STATE_METRICS_URL,KUBE_STATE_METRICS_POD_LABEL,TIMEOUT,ETCD_TLS_SECRET_NAME,ETCD_TLS_SECRET_NAMESPACE,API_SERVER_SECURE_PORT,KUBE_STATE_METRICS_SCHEME,KUBE_STATE_METRICS_PORT,SCHEDULER_ENDPOINT_URL,ETCD_ENDPOINT_URL,CONTROLLER_MANAGER_ENDPOINT_URL,API_SERVER_ENDPOINT_URL,DISABLE_KUBE_STATE_METRICS,DISCOVERY_CACHE_TTL
        image: newrelic/infrastructure-k8s:2.4.0-unprivileged
        imagePullPolicy: IfNotPresent
        resources:
            limits:
            memory: 100M
            cpu: 200m
            requests:
            cpu: 100m
            memory: 50M
        securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            runAsUser: 1000
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /var/db/newrelic-infra/data
            name: tmpfs-data
        - mountPath: /var/db/newrelic-infra/user_data
            name: tmpfs-user-data
        - mountPath: /tmp
            name: tmpfs-tmp
        - mountPath: /var/cache/nr-kubernetes
            name: tmpfs-cache
[...]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
    name: newrelic-newrelic-infrastructure-infra-agent
roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: newrelic-newrelic-infrastructure-infra-agent
subjects:
    - kind: ServiceAccount
    name: [INSERT_SERVICE_ACCOUNT_NAME_OF_WORKLOAD]
    namespace: [INSERT_SERVICE_ACCOUNT_NAMESPACE_OF_WORKLOAD]

apiVersion: v1
data:
    license: INSERT_YOUR_NEW_RELIC_LICENSE_ENCODED_IN_BASE64
kind: Secret
metadata:
    name: newrelic-newrelic-infrastructure-config
    namespace: [INSERT_NAMESPACE_OF_WORKLOAD]
type: Opaque

injection manuelle : Mise à jour vers la dernière version

Pour mettre à jour l'un des composants, il vous suffit de modifier le yaml déployé. La mise à jour de l’un des champs du conteneur injecté entraînera la recréation du pod.

injection manuelle : Désinstaller l'intégration Fargate

Pour supprimer le conteneur injecté et les ressources associées, il suffit de supprimer les éléments suivants :

• Le side-car de la charge de travail qui ne devrait plus être monitoré.
• Tous les secrets contenant la licence newrelic.
• ClusterRole et ClusterRoleBinding objets.

Notez que la suppression du conteneur sidecar entraînera la recréation du pod.

Enregistrement

Le logging New Relic n'est pas disponible sur les nœuds Fargate en raison de contraintes de sécurité imposées par AWS, mais voici quelques options de logging :

• Si vous utilisez Fluentbit pour le logging, consultez le plugin Kubernetes pour le transfert de log.
• Si vos données log sont déjà monitorées par AWS FireLens, consultez le plugin AWS FireLens pour le transfert de log.
• Si vos données log sont déjà monitorées par le log Amazon CloudWatch , consultez Log de flux à l'aide de Kinesis Data Firehose.
• Consultez AWS Lambda pour l’envoi du log CloudWatch .
• Voir Trois façons de transférer le log d'Amazon ECS vers New Relic.

Dépannage

LAST SEEN | TYPE | REASON | OBJECT | MESSAGE
:--|:--|:--|:--|:--
3m9s (x2 over 8m10s) | Warning | FailedScheduling | Pod/no-fargate-deploy-cbddd6ccf-8f9x4 | 0/2 nodes are available: 2 node(s) had untolerated taint {eks.amazonaws.com/compute-type: fargate}. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling..

LAST SEEN | TYPE | REASON | OBJECT | MESSAGE
:--|:--|:--|:--|:--
61s | Warning | FailedScheduling | Pod/newrelic-bundle-newrelic-infra-operator-admission-create-d8ggt | 0/2 nodes are available: 2 Too many pods. preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod..

Consultez vos données EKS

Voici un exemple de ce à quoi ressemble un nœud Fargate dans l'interface utilisateur de New Relic :

Pour afficher vos données AWS :

1. Accédez à one.newrelic.com > All capabilities > Infrastructure > Kubernetes et effectuez l’une des opérations suivantes :

   • Sélectionnez un nom d’intégration pour afficher les données.
   • Sélectionnez l’icône Explorer les données pour afficher les données AWS.

2. Filtrez vos données à l'aide de deux balises Fargate :

   • computeType=serverless
   • fargateProfile=[name of the Fargate profile to which the workload belongs]