0:00 Introduction

0:00 Hello, and welcome back to Rawkode Academy. I'm your host, David Flanagan. And today, we're gonna be continuing our complete guide to Parca. Today's tutorial we'll be configuring the scrape config to use Kubernetes service discovery. But first, why? Well, so far in this course, we have deployed to Parca server and seen that it doesn't really do much by default. It's a database that needs data. To provide that data, we've been using the Parca agent, which is fantastic. You deploy the Parca agent to your cluster. It runs as a daemon set, discovers the processes on the nodes using eBPF

0:10 Why Dynamic Scrape Targets? (Parca Agent vs. Dynamic Scraping)

0:43 and gets you loads of amazing profile information to get started with no with little to no effort. However, sometimes you may want to provide your own p professor information. Some languages like Node. Js and Go have fantastic support for stuff and an even more information from the runtimes themselves. So what if we want to consume that? Well, we can configure the Parca server with scrape configs, scrape targets, much like Prometheus itself. And in fact, it allows us to use the service discovery modules from the Prometheus package, and the configuration is identical. So in today's video, we're going to change

1:25 Plan and Example Scenario (Using InfluxDB2)

1:27 the config of Parca, add a scrape config using Kubernetes service discovery to filter for annotations that we just saved. I have a workload deployed to my cluster, which is influx d b two. I'm using influx d b two because it ships by default with a p professor endpoint. We're going to configure Parca to scrape that endpoint and give us all the information. So let's take a look. Okay. So let's set the scene. First, we have a default namespace, box d b two. We also have Parca namespace. Parca deployed. Please note, there is no Parca agent. Meaning,

1:54 Initial Setup and Parca UI State (No Data/Targets)

2:14 currently, Parca has no data whatsoever. This is the default install of InvoiceDB two. Nothing has been tweaked. And this is the default install of Parca. Nothing has been tweaked. We are running a port forward and another tab to the Parca UI or the Parca server. So we can pop open and hit refresh a whole bunch of times and see that nothing has changed. The Parca server has not received any data. And if we come to targets, there are no targets available. Our Parca has nothing to scrape, and nothing has been written via the push model and

2:54 the agent. So how do we get started? Well, we can modify the Parca config map. This provides everything that we need to modify and provide our own scrape target configuration. Personally, I've already prepared a config map for us to take a look at. It's a little bit bigger. And we'll see here, this is what the default Parca conflict map looks like. It just configures the bucket, in this case, file system and a directory of where to store its data. We can confirm this from the command line where we can see get config map Parca dash o channel.

2:59 Configuring Parca Scrape Targets (Modifying Parca Config Map)

3:41 You will see the default configuration. But we can change this. Right? So we can say, let's add a script config. Now remember, this is just Prometheus format for configuration. If you have configured Prometheus before to do service discovery and configure dynamic script targets, it's very much the same for Parca. We can give our job a name here. We're calling it PPROF endpoints, where we're going to rely on the Kubernetes service discovery configuration. And here, I'm asking it to find all pods. Next, we can define the relabel config. This will allow us to keep or drop

3:55 Explaining the Scrape Config (Job, Service Discovery, Relabeling)

4:25 different targets based on attributes within the target itself, the pod. So here, we can see that we only want to keep discovered pods as a target if it has a Parca. Dev slash profile annotation. You can see here we're asking for the Kubernetes metadata on the pod and annotations. This name here is just a simplified version of parka dot dev slash profile where dots and slashes are replaced with underscores. And we're just going to say keep. Now we also need to handle where the p professor information is available on different paths and on different ports.

5:12 So here, we can say that we expect an annotation of parca dot dev slash path. This will be our metrics path. Likewise, we can see the Parca dot dev slash port, and we can actually construct or compose the address from all previous information. And that's it. However, we said something a few moments ago that's worth good over again. The Kubernetes service discovery config will currently try to find all pods. The all pods is subjective and that do you want to bind it to a namespace or be cluster wide. Regardless, Parca needs some permissions in order to be able to do so.

5:35 Granting Parca Kubernetes Permissions (RBAC Setup)

6:01 As such, I've chosen to define a cluster role, which gives it the ability to watch, list, and get all pods across the entire cluster. This is not a video on Kubernetes RBAG. So if you want to do this differently, feel free. I'm just keeping things simple and easy for today's demonstration. Once we have the cluster role, we must bind it to the Parca servers account inside of the Parca namespace. Simple. So we can come back to the command line where we can run goof control and play to update the contact map and to apply the cluster role and cluster role binding.

6:34 Applying Configuration Changes (Config Map & RBAC)

6:50 Now if we can come back to Parca server, wherever we have refresh, we should see the new job for our script configuration. Like so. Okay. So we've refreshed and nothing has happened. But of course, that's because we need to do one more thing. That is we need to add our annotations to the influx DB workload. So let's jump back over to our terminal where we can go to control edit stateful set influx DB two. We can jump down to the template for all the pods where we can add our annotations. You can say parka.dev slash profile.

7:08 Adding Annotations to Workload (InfluxDB2 StatefulSet)

7:40 We can just set that to true. We also need to set our parka.dev slash path to be our path to the p professor endpoint on Parca. Dev port to eight zero eight six. Now on InfluxDB, the p professor endpoint is available at debug p professor. So now we can hit save and our Parker server will reach out to the k the Kubernetes API server, get information on the pods, find our annotations and update our target list. So let's hit refresh. And there we go. We can now see the pod IP for our influx DB pod. Debug p professor based

8:08 Verifying Scrape Targets Discovered (Target Appears in Parca)

8:32 path and it is now detected allocations, block, go routines, mutex, and point. These are now good or they all will be good in time. This now means we can head over to profiles where we have all the profiles being script. So let's just do go routines being created. Filter on our job, which is just gonna be p professor endpoints. Let go. Now we can see our new profile and information being collected from the influx d endpoint using annotations on the workload with dynamic scrape config using the Kubernetes service discovery config. Awesome. Okay. So the takeaway here is, first, if

9:21 Summary and Conclusion

9:25 you can use the Parca agent and you get everything you need, just use the Parca agent. However, if you have Google applications, Node. Js applications, other environments where you need to rely or want to consume more information using language specific integrations, they're very easy to configure. Within a Kubernetes environment, you just need to give your Parca server the right access to query nodes, services, endpoints, or pods depending on your Prometheus scrape configuration. From there, you can configure your workloads with the appropriate annotations, and the job is done. So go forth. Profile everything under Kubernetes with Parca.

10:07 Go have some fun.