La integración Kubernetes es compatible con muchas plataformas diferentes, incluidas GKE, EKS, AKS, OpenShift y más. Cada uno tiene una compatibilidad diferente con nuestra integración. Puedes encontrar más información en esta página.
Requisitos
La integración de New Relic Kubernetes requiere una cuenta de New Relic. Si aún no lo ha hecho, cree su cuenta New Relic gratuita a continuación para comenzar a monitorear sus datos hoy.
También necesitarás una distribución de Linux compatible con el agente New Relic Infrastructure .
Importante
kube-state-metrics
v2 o superior es compatible con la versión de integración 3.6.0 o mas alto.Instale la integración de Kubernetes hasta la versión 3.5.0 si estás usando
kube-state-metrics
1.9.8 o inferior.Verifique el archivo
values.yaml
si está actualizandokube-state-metrics
de v1.9.8 a v2 o superior porque algunas variables pueden cambiar.
Compatibilidad y requisitos para Helm
Cerciorar de tener Helm instalado y de que la versión mínima admitida sea la v3. La versión 3 de la integración de Kubernetes requiere la versión 3 de Helm.
Elija un nombre para mostrar para su clúster. Por ejemplo, podría emplear esta salida:
bash$kubectl config current-context
Compatibilidad y requisitos para Manifest
Si se han utilizado manifiestos personalizados en lugar de Helm, primero deberá eliminar la instalación anterior usando kubectl delete -f previous-manifest-file.yml
y luego continuar con el instalador guiado nuevamente. Esto generará un conjunto actualizado de manifiestos que se pueden desplegar usando kubectl apply -f manifest-file.yml
.
Tiempo de ejecución del contenedor
Nuestra integración de Kubernetes es independiente del CRI . Ha sido probado específicamente para ser compatible con Containerd. Tenga en cuenta que Dockershim se eliminó del proyecto Kubernetes a partir de la versión 1.24. Lea las preguntas frecuentes sobre la eliminación de Dockershim para obtener más detalles.
Compatibilidad
Importante
Si usa Openshift, también puede usar kubectl
la mayor parte del tiempo, pero tenga cuidado de que kubectl
no tenga comandos como oc login
o oc adm
. Es posible que necesites usar oc
en lugar de kubectl
.
Nuestra integración es compatible y se prueba continuamente en las siguientes versiones de Kubernetes:
Versiones | |
---|---|
Cluster de kubernetes | 1,27 a 1,31 |
Importante
A partir de la versión 1.26 de Kubernetes, @autoscaling/v2
reemplazó la API @autoscaling/v2beta2
. Para continuar con los reportes HorizontalPodAutoscaling
métricos, debe instalar kube-state-metrics
versión 2.7+ en el clúster Kubernetes versión 1.26+, porque solo kube-state-metrics
v2.7+ puede admitir la API @autoscaling/v2
.
Sabores de Kubernetes
La integración de Kubernetes es compatible con diferentes versiones. Probamos la integración con los siguientes:
Flavor | Notas |
---|---|
Minikube | |
Kind | |
K3s | |
Kubeadm | |
Servicio Amazon Elastic Kubernetes (EKS) | |
Servicio Amazon Elastic Kubernetes en cualquier lugar (EKS-Anywhere) | |
Servicio Amazon Elastic Kubernetes en Fargate (EKS-Fargate) | |
Motor Rancher Kubernetes (RKE1) | Se necesita configuración adicional para controlar los componentes del plano del instrumento. |
Servicio Azure Kubernetes (AKS) | |
Motor Google Kubernetes (GKE) | Compatible con modos estándar y piloto automático. |
Cambio abierto | Probado con la versión 4.14 |
VMware Tanzu | Compatible con VMware Tanzu (plataforma pivotal) versión 2.5 a 2.11 y Ops Manager versión 2.5 a 2.10 |
Dependiendo del método de instalación, el monitoreo del plano de control no está disponible o puede necesitar una configuración adicional.
Por ejemplo:
- Solo las métricas del servidor API son desmontables y están disponibles para el plano de control del clúster administrado por instrumentos (GKE, EKS, AKS) porque ningún extremo expone la métrica necesaria para etcd, el programador y el administrador del controlador.
- Para instrumento el plano de control de Rancher, dado que los componentes
/metrics
no siempre son accesibles de forma predeterminada y no se pueden descubrir automáticamente, se necesita alguna configuración adicional .
Requisitos de recursos
Al implementar la integración de New Relic Kubernetes , es importante asignar los recursos adecuados para garantizar que los componentes de monitoreo funcionen de manera eficiente.
A continuación se detallan los recursos mínimos aplicar y los límites recomendados para cada uno de los componentes que se despliegan en el diagrama de infraestructura .
Componente kubelet
Los siguientes contenedores están incluidos en el componente Kubelet pod desplegar en cada nodo.
Contenedor Kubelet
UPC:
- Pedido:
100m
- Pedido:
memoria:
- Pedido:
150M
- Límite:
300M
- Pedido:
agente de contenedores
UPC:
- Pedido:
100m
- Pedido:
memoria:
- Pedido:
150M
- Límite:
300M
- Pedido:
Componente de métrica de estado de Kube
Contenedor KSM
UPC:
- Pedido:
100m
- Pedido:
memoria:
- Pedido:
150M
- Límite:
850M
- Pedido:
Transportador de contenedores
UPC:
- Pedido:
100m
- Pedido:
memoria:
- Pedido:
150M
- Límite:
850M
- Pedido:
Componente del plano de control
UPC:
- Pedido:
100m
- Pedido:
memoria:
- Pedido:
150M
- Límite:
300M
- Pedido:
agente de contenedores
UPC:
- Pedido:
100m
- Pedido:
memoria:
- Pedido:
150M
- Límite:
300M
- Pedido:
Los siguientes son los recursos recomendados que aplicar y los límites que requieren otros componentes que se implementan como parte del paquete nri.
inyección de metadatos
UPC:
- Pedido:
100m
- Pedido:
memoria:
- Pedido:
30M
- Límite:
80M
- Pedido:
Logging
Los siguientes contenedores están incluidos en el pod de logging de New Relic que se despliega en cada nodo.
UPC:
- Pedido:
250m
- Límite:
500m
- Pedido:
memoria:
- Pedido:
64M
- Límite:
128M
- Pedido:
Consideraciones
Tamaño del clúster: estas recomendaciones de recursos son para tamaños de clúster típicos. Un clúster más grande con más nodos y pods puede requerir mayores asignaciones de recursos para manejar el volumen de datos adicional.
Configuración personalizada: si habilita características adicionales o configuraciones personalizadas, considere ajustar los recursos en consecuencia.
Monitoreo y ajuste: luego de la implementación, monitoree el uso de recursos de estos pods y ajuste las solicitudes y los límites según el uso real para optimizar el rendimiento y el costo.
Estas especificaciones de recursos se pueden ajustar en el archivo values.yaml
del diagrama de Helm empleado para implementar la integración de New Relic Kubernetes . Al garantizar que se cumplan estos requisitos de recursos, puede mantener un monitoreo eficiente y efectivo de su clúster de Kubernetes con New Relic.