{"id":820,"date":"2024-04-15T12:34:56","date_gmt":"2024-04-15T12:34:56","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=820"},"modified":"2024-04-15T12:34:56","modified_gmt":"2024-04-15T12:34:56","slug":"setup-prometheus-operator","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=820","title":{"rendered":"How to Setup Prometheus Operator on Kubernetes"},"content":{"rendered":"

In this blog, we are going to set up and configure the Prometheus Operator.<\/strong><\/p>\n

The Prometheus is not a native object of the Kubernetes, but we can make it a Kubernetes <\/strong>native object using the Prometheus operators.<\/strong><\/p>\n

What is Prometheus Operator<\/strong><\/h2>\n

Prometheus Operator<\/strong> is a Kubernetes Custom Controller<\/strong> that can communicate with the Kubernetes API Server <\/strong>and allow Prometheus to do the operations.<\/p>\n

We will install Prometheus on our Kubernetes cluster but the main moto of installing the Prometheus Operator<\/strong> is to reduce the complexity of the configuration.<\/p>\n

In normal Prometheus deployment, configMap<\/code> is an important object where we inform the targets and rules information to the Prometheus.<\/p>\n

Instead of that, the Prometheus Operator has dedicated objects for that. For example, prometheusRuler<\/code> for rules, podMonitor<\/code> object for monitoring the Pods, scrapeConfig<\/code> object for static targets and more.<\/p>\n

In a normal Prometheus stack, if you want to make any modifications that will disturb the present configuration, but in the Prometheus Operator, we can make the configuration changes whenever we want, and also, the current state won’t be disturbed.<\/p>\n

If you set up the Prometheus operators<\/strong>, you won’t feel that the Prometheus <\/strong>is an external object, and it will simplify the overall integration and configuration process.<\/p>\n

If you want to install Prometheus on your Kubernetes cluster without the Operator, here is the blog<\/a>.<\/p>\n

Prometheus Operator Workflow<\/h2>\n
\"prometheus<\/figure>\n
    \n
  1. Prometheus Operator keeps watching its Custom Resource Definitions<\/strong>.<\/li>\n
  2. We inform the Operator via Custom Resource what outcome we are expecting.<\/li>\n
  3. For example, I am telling on a Custom Resource that I have a service, and the service’s endpoint should be monitored.<\/li>\n
  4. The operator will get this information from the CRD and will do the required changes.<\/li>\n
  5. But the Operator has all the logic in it, which means that the operator will identify the Service with the labels that we provide and collect the endpoint information then make a structure and place it on the Prometheus instance.<\/li>\n<\/ol>\n

    What are the Prometheus Supported Custom Resource Definitions<\/strong><\/h2>\n

    Prometheus<\/strong><\/h3>\n

    Prometheus Custom Resource Definition <\/strong>(CRD) is used to create the Prometheus Custom Resource, <\/strong>or we can simply say the Prometheus deployment on the Kubernetes <\/strong>cluster also offers the replication and storage related configuration. <\/p>\n

    Alertmanager<\/strong><\/h3>\n

    Alertmanager CRD is used to create an Alertmanager deployment on the cluster.<\/p>\n

    ThanosRuler<\/strong><\/h3>\n

    ThanosRuler CRD manages and validates the Prometheus Recording Rules and the Alerting Rules.<\/p>\n

    ServiceMonitor<\/strong><\/h3>\n

    ServiceMonitor CRD helps add the Kubernetes services to the Prometheus Custom Resources.<\/p>\n

    PodMonitor<\/strong><\/h3>\n

    PodMonitor CRD is used to add the Pods on the Prometheus Custom Resource.<\/p>\n

    Probe<\/strong><\/h3>\n

    Probe CRD is used to add the static targets on the Prometheus Custom Resource.<\/p>\n

    PrometheusRule<\/strong><\/h3>\n

    Add alerting rules and recording rules on the Prometheus.<\/p>\n

    AlertmanagerConfig<\/strong><\/h3>\n

    Alertmanager-related configuration such as inhibition, routing, silencing, etc.<\/p>\n

    Prometheus Operator Setup – Helm<\/strong><\/h2>\n

    The Helm chart will deploy all the Prometheus Operator components, such as Custom Resource Definitions and Deployments.<\/p>\n

    \"prometheus<\/figure>\n

    Prerequisites<\/strong><\/h3>\n
      \n
    1. Kubernetes cluster v1.31 or higher.<\/li>\n
    2. kubectl v1.31 or higher should be available on the local system.<\/li>\n
    3. Helm v3.16 or higher should be available on the local system.<\/li>\n<\/ol>\n

      Note: If you are using an EKS cluster, suitable VPC-CNI should be available in the cluster.<\/p>\n

      To install the VPC-CNI, use this official documentation.<\/a><\/p><\/blockquote>\n

      Add the Prometheus community Helm chart.<\/p>\n

      helm repo add prometheus-community https:\/\/prometheus-community.github.io\/helm-charts<\/code><\/pre>\n
      Update the Helm repository<\/p>\n
      helm repo update<\/code><\/pre>\n
      Before the installation of the operator, we need to get the values file of the helm chart so that we can make configuration changes if we want.<\/p>\n
      To get the values file, use the following command.<\/p>\n
      helm show values prometheus-community\/kube-prometheus-stack > values.yaml<\/code><\/pre>\n
      Now, we can install the Prometheus Operator using the Helm<\/p>\n
      helm install prometheus prometheus-community\/kube-prometheus-stack -n prometheus-operator --create-namespace<\/code><\/pre>\n
      It will take a few minutes to complete the setup; once it is completed, we can check the Pods.<\/p>\n
      kubectl get pods -n prometheus-operator<\/code><\/pre>\n
      \"prometheus<\/figure>\n
      In this, Grafana, Prometheus Operator<\/strong> and Kube State Metrics<\/strong> are deployed as Deployment<\/strong> Objects.<\/p>\n
      kubectl get deployments -n prometheus-operator<\/code><\/pre>\n
      \"prometheus<\/figure>\n
      Grafana:<\/strong> Visualize the metrics<\/p>\n
      Prometheus Operator:<\/strong> It is a controller to manage and configure the Prometheus stack<\/p>\n
      Kube state metrics:<\/strong> Collect the Kubernetes API Server metrics<\/p>\n
      Alertmanager<\/strong> and Prometheus<\/strong> are deployed as StatefulSets.<\/strong><\/p>\n
      kubectl get statefulsets -n prometheus-operator<\/code><\/pre>\n
      \"Prometheus<\/figure>\n
      Alertmanager:<\/strong> Sending alerts via email or notifications<\/p>\n
      Prometheus:<\/strong> Collect metrics<\/p>\n

      \nPrometheus and Alertmanager are deployed as StatefulSet<\/strong> objects because Prometheus has the Time Series Database<\/strong> that stores the metrics, and both these Objects have configurations, so it does need persistent volumes.<\/span>
      \n<\/p>\n
      Because of the persistent volume, the data will persist even if the Pod is removed or rescheduled.<\/p>\n
      The Node Exporter<\/strong> is deployed as a Daemonset<\/strong> because this object ensures that the Node Exporter is available on each node to collect the metrics.<\/p>\n
      kubectl get daemonsets -n prometheus-operator<\/code><\/pre>\n
      \"prometheus<\/figure>\n
      Now, let’s view their intended Services.<\/p>\n
      kubectl get svc -n prometheus-operator<\/code><\/pre>\n
      \"Prometheus<\/figure>\n
      Deploying the Prometheus Operator will create custom resources to monitor the default Kubernetes resources, such as nodes, API server, kube-proxy, kubelet, etc.<\/p>\n
      We need to perform the port forwarding to see the web UI of Prometheus, Alertmanager, or Grafana.<\/p>\n
      For that, we need the service name<\/strong> prometheus-kube-prometheus-prometheus <\/code>and the related port number<\/strong> 9090<\/code>.<\/p>\n
      To view the Dashboard of the Prometheus<\/strong>, use the following command.<\/p>\n
      kubectl port-forward -n prometheus-operator svc\/prometheus-kube-prometheus-prometheus 9090:9090<\/code><\/pre>\n
      Now, open any of the web browsers from your local machine and paste the URL localhost:9090<\/code>.<\/p>\n
      \"prometheus<\/figure>\n
      In the target section of the dashboard, we can see some of the targets are pre-configured.<\/p>\n
      \"the<\/figure>\n
      These Custom Resources<\/strong> are created by using the ServiceMonitor<\/code> Custom Resource Definition<\/strong>.<\/p>\n
      kubectl get servicemonitors -n prometheus-operator<\/code><\/pre>\n
      \"Prometheus<\/figure>\n
      To see the dashboard of the Alertmanager<\/strong>, use the following command.<\/p>\n
      kubectl port-forward --namespace prometheus-operator svc\/prometheus-kube-prometheus-alertmanager 9093:9093<\/code><\/pre>\n
      Let’s try to access the dashboard from our local system localhost:9093<\/code>.<\/p>\n
      \"prometheus<\/figure>\n
      Most of the configurations are already defined and if you want modifications you can do it, also in this setup, by default, you can’t access the dashboards of the services such as Prometheus, Alertmanager, Grafana, etc.<\/p>\n
      So, if you want to access the internet, you need to create a new Service object for them with the type NodePort <\/strong>or Loadbalancer.<\/strong><\/p>\n
      To view the list of all the Custom Resource Definitions<\/strong> related to the Prometheus Operator.<\/p>\n
      kubectl get crds -n prometheus-operator<\/code><\/pre>\n
      \"Prometheus<\/figure>\n
      With these custom resource definitions, you can create as many custom resources as you want.<\/p>\n
      How to Install Prometheus Operator<\/strong> – YAML Manifest<\/h2>\n
      In this method, you can customize the Prometheus Operator installation. For example, if you only want Prometheus but don’t need Alertmanager or Grafana, you can easily do that with this setup.<\/p>\n
      Download the bundle.yaml<\/strong> file from the Prometheus Operator GitHub repository<\/strong> to define the Prometheus Custom Resource Definitions<\/strong> and the Prometheus Operator.<\/strong><\/p>\n
      wget https:\/\/github.com\/prometheus-operator\/prometheus-operator\/releases\/download\/v0.79.2\/bundle.yaml<\/code><\/pre>\n
      Use the following command to deploy the Custom Resource Definitions (CRDs) <\/strong>to the cluster.<\/p>\n
      kubectl create -f bundle.yaml<\/code><\/pre>\n
      These resources will be deployed in the default <\/strong>namespace, and currently, only the Prometheus Operator and the CRDs are deployed.<\/p>\n
      kubectl get deployments -n default<\/code><\/pre>\n
      To view and filter the Prometheus Operator Custom Resource Definitions<\/strong>.<\/p>\n
      kubectl get crds | grep \"monitoring.coreos.com\"<\/code><\/pre>\n
      Test the Prometheus Operator with an Application<\/h2>\n
      To test the workflow of the Prometheus Operator, we need a target application.<\/p>\n
      We are using an application for testing purposes, and you have to ensure that the application should be instrumented with the Prometheus Client Libraries. <\/p>\n
      For testing purposes, I will deploy this application with three replicas and create a service for this deployment.<\/p>\n
      Then, I will use the ServiceMonitor Custom Resource to collect the metrics from the service endpoints, basically the deployment’s three replica pods.<\/p>\n
      \"prometheus<\/figure>\n
      First, we need to create a Deployment manifest for the application instrumented-app-deploy.yaml<\/code><\/p>\n
      apiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: example-app\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: example-app\n  template:\n    metadata:\n      labels:\n        app: example-app\n    spec:\n      containers:\n      - name: example-app\n        image: fabxc\/instrumented_app\n        ports:\n        - name: web\n          containerPort: 8080<\/code><\/pre>\n
      This application will expose the metrics at Port 8080,<\/strong> and I am providing three replicas for this application.<\/p>\n
      To deploy this application, use the following command.<\/p>\n
      kubectl apply -f instrumented-app-deploy.yaml<\/code><\/pre>\n
      Check the Deployment and Pods to ensure the deployment is properly done.<\/p>\n
      Now, I am creating a service file for this application instrumented-app-svc.yaml<\/code><\/p>\n
      apiVersion: v1\nkind: Service\nmetadata:\n  name: example-app\n  labels:\n    app: example-app\nspec:\n  selector:\n    app: example-app\n  ports:\n  - name: web\n    port: 8080<\/code><\/pre>\n
      To deploy this application service, use the following command.<\/p>\n
      kubectl apply -f instrumented-app-svc.yaml<\/code><\/pre>\n
      We need to ensure this application service is running properly.<\/p>\n
      kubectl get svc<\/code><\/pre>\n
      Create Service Monitor Custom Resource<\/strong><\/h2>\n
      ServiceMonitor<\/strong> Custom Resource is used to collect the metrics from the service endpoints.<\/p>\n
      Labels<\/strong> play an important role in these configurations, so provide your labels simple and meaningful.<\/p>\n
      I am going to use the labels of the Service as the Selector of the ServiceMonitor<\/code> object.<\/p>\n
      Now, we have to create the ServiceMonitor Custom Resource file service-monitor-cr.yaml<\/code><\/p>\n
      apiVersion: monitoring.coreos.com\/v1\nkind: ServiceMonitor\nmetadata:\n  name: example-app\n  labels:\n    team: frontend\nspec:\n  selector:\n    matchLabels:\n      app: example-app\n  endpoints:\n  - port: web<\/code><\/pre>\n
      Here, you can see, under the spec<\/code> section, I have provided the label of the application service app: example-app<\/code>. This is how ServiceMonitor identifies the service object and its endpoints.<\/p>\n
      To apply this configuration, use the following command.<\/p>\n
      kubectl apply -f service-monitor-cr.yaml<\/code><\/pre>\n
      To list the ServiceMonitor object.<\/p>\n
      kubectl get servicesmonitor<\/code><\/pre>\n
      Create a Service Account<\/strong><\/h2>\n
      If you are performing RBAC authorization<\/strong> on your cluster, then first you need to set up the ClusterRole<\/strong> and ClusterRoleBinding<\/strong> with a ServiceAccount.<\/strong><\/p>\n
      Create a service account file service-account.yaml<\/code><\/p>\n
      apiVersion: v1\nkind: ServiceAccount\nmetadata:\n  name: prometheus-operator-svc-ac<\/code><\/pre>\n
      To apply this configuration, use the following command.<\/p>\n
      kubectl apply -f service-account.yaml<\/code><\/pre>\n
      To list the service accounts in the current namespace.<\/p>\n
      kubectl get serviceaccount<\/code><\/pre>\n
      Create ClusterRole<\/strong><\/h2>\n
      Create a ClusterRole file clusterrole.yaml<\/code> and provide the necessary permission for the cluster-scoped resources.<\/p>\n
      apiVersion: rbac.authorization.k8s.io\/v1\nkind: ClusterRole\nmetadata:\n  name: prometheus\nrules:\n- apiGroups: [\"\"]\n  resources:\n  - nodes\n  - nodes\/metrics\n  - services\n  - endpoints\n  - pods\n  verbs: [\"get\", \"list\", \"watch\"]\n- apiGroups: [\"\"]\n  resources:\n  - configmaps\n  verbs: [\"get\"]\n- apiGroups:\n  - networking.k8s.io\n  resources:\n  - ingresses\n  verbs: [\"get\", \"list\", \"watch\"]\n- nonResourceURLs: [\"\/metrics\"]\n  verbs: [\"get\"]<\/code><\/pre>\n
      To apply this configuration, use the following command.<\/p>\n
      kubectl apply -f clusterrole.yaml<\/code><\/pre>\n
      To list the cluster roles in the current namespace.<\/p>\n
      kubectl get clusterrole prometheus<\/code><\/pre>\n
      Create ClusterRoleBinding<\/strong><\/h2>\n
      Create a ClusterRoleBinding file clusterrolebinding.yaml<\/code> and integrate the information about the ClusterRole and the ServiceAccount.<\/p>\n
      apiVersion: rbac.authorization.k8s.io\/v1\nkind: ClusterRoleBinding\nmetadata:\n  name: prometheus\nroleRef:\n  apiGroup: rbac.authorization.k8s.io\n  kind: ClusterRole\n  name: prometheus\nsubjects:\n- kind: ServiceAccount\n  name: prometheus-operator-svc-ac\n  namespace: default<\/code><\/pre>\n
      To apply this configuration, use the following command.<\/p>\n
      kubectl apply -f clusterrolebinding.yaml<\/code><\/pre>\n
      To view the details about the ClusterRoleBinding.<\/strong><\/p>\n
      kubectl describe clusterrolebinding prometheus<\/code><\/pre>\n
      If the configuration is properly done, you can able to see the ClusterRole, ServiceAccount, and Namespace<\/strong> names in the details of the ClusterRoleBinding.<\/p>\n
      Create a Prometheus Custom Resource<\/strong><\/h2>\n
      Now, we need to create the Prometheus Custom Resources and also add the information about the ServiceAccount<\/strong> and the ServiceMonitor<\/strong>.<\/p>\n
      Create a configuration file to deploy the Prometheus Custom Resource <\/strong>Prometheus-cr.yaml<\/code><\/p>\n
      apiVersion: monitoring.coreos.com\/v1\nkind: Prometheus\nmetadata:\n  name: prometheus\nspec:\n  serviceAccountName: prometheus-operator-svc-ac\n  serviceMonitorSelector:\n    matchLabels:\n      team: frontend\n  resources:\n    requests:\n      memory: 400Mi\n  enableAdminAPI: false<\/code><\/pre>\n
      In this configuration, I am providing the value for the spec.serviceMonitorSelector.matchLabels <\/code>is the label of the ServiceMonitor Object that we created earlier.<\/p>\n
      This is how the Prometheus grabs the target details with the help of the ServiceMonitor Custom Resource<\/strong><\/p>\n
      To apply this configuration, use the following command.<\/p>\n
      kubectl apply -f prometheus-cr.yaml<\/code><\/pre>\n
      To list the Prometheus object.<\/p>\n
      kubectl get prometheus<\/code><\/pre>\n
      I want to access <\/strong>Prometheus over the internet, so I am creating a service with nodePort<\/strong>. Create a service file prometheus-cr-svc.yaml<\/code><\/p>\n
      apiVersion: v1\nkind: Service\nmetadata:\n  name: prometheus\nspec:\n  type: NodePort\n  ports:\n  - name: web\n    nodePort: 30900\n    port: 9090\n    protocol: TCP\n    targetPort: web\n  selector:\n    prometheus: prometheus<\/code><\/pre>\n
      To deploy this service, use the following command.<\/p>\n
      kubectl apply -f prometheus-cr-svc.yaml<\/code><\/pre>\n
      List the services to ensure they are running and note down the nodePort<\/strong> number.<\/p>\n
      Open any browser and paste any of the instance’s public IPs and the port number, and then you will get this same output.<\/p>\n
      \"prometheus<\/figure>\n
      Here, we can see three Pods have been monitored because I gave three replicas for the application. ServiceMonitor got the endpoint information of the three of them as well, and Prometheus got it from the ServiceMonitor.<\/strong><\/p>\n
      If the Pods dont’ have service, we can use the PodMonitor Custom Resource <\/strong>to monitor them directly.<\/p>\n
      Create AlertmanagerConfig Custom Resource<\/strong><\/h2>\n
      We need Alertmanager to send the notifications to the receiver based on the Prometheus rules.<\/strong><\/p>\n
      But before that, we need to create the AlertmanagerConfig<\/strong> Custom Resource with the routing and receiver information.<\/p>\n
      Create a manifest for the AlertmanagerConfig<\/strong> Object alertmanager-config-cr.yaml<\/code><\/p>\n
      apiVersion: monitoring.coreos.com\/v1alpha1\nkind: AlertmanagerConfig\nmetadata:\n  name: config-example\n  labels:\n    alertmanagerConfig: example\nspec:\n  route:\n    groupBy: ['job']\n    groupWait: 30s\n    groupInterval: 5m\n    repeatInterval: 12h\n    receiver: 'webhook'\n  receivers:\n  - name: 'webhook'\n    webhookConfigs:\n    - url: 'http:\/\/example.com\/'<\/code><\/pre>\n
      To deploy this configuration, use the following command.<\/p>\n
      kubectl apply -f alertmanager-config-cr.yaml<\/code><\/pre>\n
      To list the AlertmanagerConfig<\/strong> object.<\/p>\n
      kubectl get alertmanager<\/code><\/pre>\n
      AlertmanagerConfig contains the configuration information for Alertmanager.<\/p>\n
      Create Alertmanager Custom Resource<\/strong><\/h2>\n
      Create a manifest for the Alertmanager<\/strong> Object alertmanager-cr.yaml<\/code> <\/strong>and add the following contents.<\/p>\n
      apiVersion: monitoring.coreos.com\/v1\nkind: Alertmanager\nmetadata:\n  name: example\nspec:\n  replicas: 3\n  alertmanagerConfigSelector:\n    matchLabels:\n      alertmanagerConfig: example<\/code><\/pre>\n
      Here, you can see that spec.alertmanagerConfigSelector<\/code> pointing to the AlertmanagerConfig <\/strong>Custom Resource labels.<\/p>\n
      To apply this configuration, use the following command.<\/p>\n
      kubectl apply -f alertmanager-cr.yaml<\/code><\/pre>\n
      To view the Alertmanager Custom Resource.<\/p>\n
      kubectl get alertmanager<\/code><\/pre>\n
      I am creating a service for the Alertmanager Custom Resource<\/strong> to access it over the internet.<\/p>\n
      Create a service file alertmanager-cr-svc.yaml<\/code><\/p>\n
      apiVersion: v1\nkind: Service\nmetadata:\n  name: alertmanager-example\nspec:\n  type: NodePort\n  ports:\n  - name: web\n    nodePort: 30903\n    port: 9093\n    protocol: TCP\n    targetPort: web\n  selector:\n    alertmanager: example<\/code><\/pre>\n
      To apply this configuration, use the following command.<\/p>\n
      kubectl apply -f alertmanager-cr-svc.yaml<\/code><\/pre>\n
      Now, we can access the Alertmanager dashboard over the internet, but before that, ensure the Pod is running properly.<\/p>\n
      To access the dashboard, we need the nodePort<\/strong> number 30903<\/code> and the Public IP<\/strong> of any one of the instances.<\/p>\n
      \"prometheus<\/figure>\n
      Initially, when we deployed the Prometheus Custom Resource<\/strong>, didn’t mention anything about the Alertmanager,<\/strong> so now, we need to make some changes in the existing Prometheus configuration file prometheus-cr.yaml.<\/code><\/p>\n
      apiVersion: monitoring.coreos.com\/v1\nkind: Prometheus\nmetadata:\n  name: prometheus\nspec:\n  serviceAccountName: prometheus-operator-svc-ac\n\n  replicas: 2\n\n  alerting:\n    alertmanagers:\n    - namespace: default\n      name: alertmanager-example\n      port: web\n\n  serviceMonitorSelector:\n    matchLabels:\n      team: frontend\n  resources:\n    requests:\n      memory: 400Mi\n  enableAdminAPI: false<\/code><\/pre>\n
      Now, we have to redeploy this manifest to update the changes, and this modification will not affect the existing setup.<\/p>\n
      kubectl apply -f prometheus-cr.yaml<\/code><\/pre>\n
      If we check the Prometheus dashboard now, we can see the Alertmanager information in the dashboard.<\/p>\n
      \"prometheus<\/figure>\n
      Advantages Of Prometheus Operator<\/strong><\/h2>\n
      Here are the few advantages of Prometheus Operator.<\/p>\n
        \n
      1. If you are fed up with the manual integration of the Prometheus in the Kubernetes, you can use the operators because the setup process is really easy.<\/li>\n
      2. In the manual configuration, you might face some inconsistencies if you are working in multiple clusters, but if you are using operators, then the Custom Resource Definition (CRD) will ensure consistency across the cluster.<\/li>\n
      3. Manual configuration modification is complex if you are required to handle the scaling process in the Prometheus stack, but the operators will simplify the process and automate the job.<\/li>\n
      4. Integrating other components, such as Alertmanager and Grafana, is also easy when compared to manual integration, and you will not be confused about the configurations because the Prometheus manifests are the same as the Kubernetes native objects manifest.<\/li>\n<\/ol>\n
        Conclusion<\/strong><\/h2>\n
        I have tried this setup to learn how to configure the Prometheus Custom Resource. <\/strong>I have also done a test setup to explain the concept, but you can do more in the configuration segment.<\/p>\n
        Also, try the other Custom Resources such as PodMonitor, Probe, ThanosRuler, etc.<\/p>\n
        Know about their use cases and implement them if your requirements need them. You can also create your custom resources if you want.<\/p>\n
        \n
        Ngu\u1ed3n:<\/strong> How to Setup Prometheus Operator on Kubernetes \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
        Source: https:\/\/devopscube.com\/setup-prometheus-operator\/<\/p>\n","protected":false},"author":1,"featured_media":821,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-820","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/820","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=820"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/820\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/821"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=820"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=820"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=820"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}