現在、このページは英語版のみです。

In 2016, the operator concept was introduced by CoreOS Linux. Its purpose was to extend the capabilities of Kubernetes APIs, and it continues the tradition of one of the core designs of Kubernetes: automation. Operators simplify the process of managing complex Kubernetes applications—which can be made up of multiple deployments, pods, services, and more—by abstracting the resources into a set of custom configurations, or custom resources (CR). 

This means that you can use an operator to manage tasks for your Kubernetes applications, including deploying, scaling, and upgrading, without needing to access anything more than the custom resources. Operators do this by allowing you to encode directions and best practices for specific applications on Kubernetes. As part of the Kubernetes control plane, operators act as controllers that continuously check for and resolve discrepancies between the current state of the cluster and the desired state you have configured through custom resource definitions (CRD). 

In this blog post, you’ll learn how to get started with the New Relic operator for the Kubernetes integration, the benefits of using the operator, and how to update an example configuration.

Why you should use the New Relic Kubernetes Operator

If you’re already using the New Relic Kubernetes integration to monitor your clusters, you’re likely familiar with the features and capabilities the platform offers for your Kubernetes data, including the ability to:

With the New Relic Kubernetes operator, you can now easily deploy the integration, which includes multiple modules (including Pixie, Fluentbit, and Prometheus) to monitor and manage your cluster, and also get additional automation features. For example, instead of having to configure or upgrade multiple pieces of your architecture one by one, you simply tell the operator what you want, and it’ll take care of it for you. It can even redeploy secrets or pods if you need it to! 

The New Relic Kubernetes operator can also help ease the burden of other processes, including:

  • Scaling applications in and out
  • Initiating upgrades 
  • Deploying an application on demand

One thing to note here is that you can also install the New Relic Kubernetes integration without the operator; the operator exists to simplify the process of installing the integration and other common Kubernetes processes.

 

How to use the Kubernetes operator

For this brief how-to, you’ll need:

First, make sure you have Kubernetes running on your machine. Then, follow the remaining steps to install the New Relic Kubernetes integration using the operator.

  1. Run minikube start.
  2. Runhelm repo add nr-operator https://newrelic.github.io/newrelic-k8s-operator && helm repo update to add the operator.
  3. Copy the script in the following code snippet and paste it in a text editor. You’ll use this script to configure and deploy the operator in your cluster, but first you need to update some values.
function ver { printf "%03d%03d" $(echo "$1" | tr '.' ' '); } && \
K8S_VERSION=$(kubectl version --short 2>&1 | grep 'Server Version' | awk -F' v' '{ print $2; }' | awk -F. '{ print $1"."$2; }') && \
if [[ $(ver $K8S_VERSION) -lt $(ver "1.25") ]]; then KSM_IMAGE_VERSION="v2.6.0"; else KSM_IMAGE_VERSION="v2.7.0"; fi && \
helm repo add newrelic https://helm-charts.newrelic.com && helm repo update && \
kubectl create namespace [YOUR_NAMESPACE] ; helm upgrade --install newrelic-bundle nr-operator/newrelic-k8s-operator \
kubectl create namespace [YOUR_NAMESPACE] ; helm upgrade --install newrelic-bundle newrelic/nri-bundle \
 --set global.licenseKey=[YOUR_INGEST_LICENSE_KEY] \
 --set global.cluster=[YOUR_CLUSTER_NAME] \
 --namespace=[YOUR_NAMESPACE] \
 --set newrelic-infrastructure.privileged=true \
 --set global.lowDataMode=true \
 --set kube-state-metrics.image.tag=${KSM_IMAGE_VERSION} \
 --set kube-state-metrics.enabled=true \
 --set kubeEvents.enabled=true \
 --set newrelic-prometheus-agent.enabled=true \
 --set newrelic-prometheus-agent.lowDataMode=true \
 --set newrelic-prometheus-agent.config.kubernetes.integrations_filter.enabled=false \
 --set logging.enabled=true \
 --set newrelic-logging.lowDataMode=true 

4. Replace the following fields in the script:

  1. [YOUR_NAMESPACE] with your desired namespace
  2. [YOUR_INGEST_LICENSE_KEY] with your account’s ingest license key
  3. [YOUR_CLUSTER_NAME] with your desired cluster name

5. Note that the script includes the following settings, which can be reconfigured if you wish:

  1. It scrapes all Prometheus endpoints except core Kubernetes system metrics
  2. It forwards all logs with minimal enrichment (low data mode).
  3. If you have Pixie set up, you can also enable instant service-level insights, full-body requests, and application profiles

6. Once you’ve replaced the fields from step 4 with your own values, run the entire script in your terminal. This will deploy the New Relic operator to your cluster, which will then also deploy the Kubernetes integration.

To confirm that your script was successful, run kubectl get pods --namespace [YOUR_NAMESPACE]. You should see a list like the one below. The pods shown here are part of the New Relic Kubernetes integration that you just installed; you can learn more about these components the New Relic helm-charts repo.

8. There are two custom resources you can modify: Monitor and NRIBundle. To modify the configuration of either of those CRs in the terminal, run kubectl edit nribundle -n [YOUR_CLUSTER_NAME] or kubectl edit monitor -n [YOUR_CLUSTER_NAME] and make your desired changes; these will be automatically applied without the need to run helm again.

Exploring your Kubernetes data

Navigate to your New Relic account to view your fresh Kubernetes data: select All Entities > then select Containers to take a look at your container entities.

The entities shown here are deployments that are running in your current Kubernetes cluster. If you have applications deployed, you would see them in this list as well; otherwise, you would just see the ones that Kubernetes itself needs to run. For example, coredns is what Kubernetes uses to resolve DNS within the cluster.

If you scroll down in the left-hand navigation, you will see the Kubernetes section, and be able to drill down further into your clusters, daemonsets, pods, and more. Continue exploring the New Relic Kubernetes experience by reading more in the documentation.