This Stackoverflow question piqued my interest: retry policy configuration for grpc not working Service Config in gRPC is new to me but, my initial suspicion (albeit incorrect) was that the JSON types were incorrect. I decided to try using the Protocol Buffer source service_config.proto to verify the JSON. To do so I needed to compile the source…. it was gnarly. There are 2 repos used: googleapis grpc-proto The service_config.proto includes options for java_package but no go_package.

Ackal deploys gRPC Health Checking clients in locations around the World in order to health check services that are representative of customer need. Koyeb offers multiple locations and I spent time today writing a client for Ackal to integrate with Koyeb using the Golang client for the Koyeb API. The SDK is generated from Koyeb’s OpenAPI (nee Swagger) endpoint using openapi-generator-cli. This is a smart, programmatic solution to ensuring that the SDK always matches the API definition but I found the result is idiosyncratic and therefore a little gnarly.

The deployment of Kube State Metrics for Google Managed Prometheus creates both a PodMonitoring and ClusterPodMonitoring. The PodMonitoring resource exposes metrics published on metric-self port (8081). The ClusterPodMonitoring exposes metrics published on metric port (8080) but this doesn’t include cronjob-related metrics: kubectl get clusterpodmonitoring/kube-state-metrics \ --output=jsonpath="{.spec.endpoints[0].metricRelabeling}" \ | jq -r . [ { "action": "keep", "regex": "kube_(daemonset|deployment|replicaset|pod|namespace|node|statefulset|persistentvolume|horizontalpodautoscaler|job_created)(_.+)?", "sourceLabels": [ "__name__" ] } ] NOTE The regex does not include kube_cronjob and only includes kube_job_created patterns.

Referring to Accessing Google Services using gRPC, I wanted to query a project’s Cloud Logging for log-based metrics using gRPC. In summary: ENDPOINT="logging.googleapis.com:443" ROOT="/path/to/googleapis" # https://github.com/googleapis/googleapis PACKAGE="google/logging/v2" # NB Not logging.proto PROTO="${ROOT}/${PACKAGE}/logging_metrics.proto" TOKEN=$(gcloud auth print-access-token) PROJECT="..." PACKAGE="google.logging.v2" SERVICE="MetricsServiceV2" METHOD="${PACKAGE}.${SERVICE}/ListLogMetrics" # ListLogMetricsRequest fields PARENT="projects/${PROJECT}" grpcurl \ --import-path=${ROOT} \ --proto=${PROTO} \ -H "Authorization: Bearer ${TOKEN}" \ -d "{\"parent\": \"${PARENT}\"}" \ ${ENDPOINT} ${METHOD} From APIs Explorer, Cloud Logging API v2, instead of the REST reference, browse the gRPC reference specifically the package google.

CRD linting Returning to yesterday’s failing tests, it’s unclear how to introspect the E2E tests. kubectl get namespaces NAME STATUS AGE ... allns-s2os2u-0-90f56669 Active 22h allns-s2qhuw-0-6b33d5eb Active 4m23s kubectl get all \ --namespace=allns-s2os2u-0-90f56669 No resources found in allns-s2os2u-0-90f56669 namespace. kubectl get all \ --namespace=allns-s2qhuw-0-6b33d5eb NAME READY STATUS RESTARTS AGE pod/prometheus-operator-6c96477b9c-q6qm2 1/1 Running 0 4m12s pod/prometheus-operator-admission-webhook-68bc9f885-nq6r8 0/1 ImagePullBackOff 0 4m7s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/prometheus-operator ClusterIP 10.152.183.247 <none> 443/TCP 4m9s NAME READY UP-TO-DATE AVAILABLE AGE deployment.

For ackalctld to be deployable to Kubernetes with Prometheus Operator, it is necessary to Enable ScrapeConfig to use (discovery|target) proxies #5966. While I’m familiar with Kubernetes, Kubernetes operators (Ackal uses one built with the Operator SDK) and Prometheus Operator, I’m unfamiliar with developing Prometheus Operator. This (and subsequent) posts will document some preliminary work on this. Cloned Prometheus Operator Branched scrape-config-url-proxy I’m unsure how to effect these changes and unsure whether documentation exists.

TL;DR Enable ScrapeConfig to use (discovery|target) proxies I’ve developed a companion, local daemon (called ackalctld) for Ackal that provides a functionally close version of the service. One way to deploy ackalctld is to use Kubernetes and it would be convenient if the Prometheus metrics were scrapeable by Prometheus Operator. In order for this to work, Prometheus Operator needs to be able to scrape Google Cloud Run targets because ackalctld creates Cloud Run services for its health check clients.

Yet another cloud platform exporter for resource|cost management. This time for Koyeb with Koyeb Exporter. Deploying resources to cloud platforms generally incurs cost based on the number of resources deployed, the time each resource is deployed and the cost (per period of time) that the resource is deployed. It is useful to be able to automatically measure and alert on all the resources deployed on all the platforms that you’re using and this is an intent of these exporters.

Responded to Get Custom K8s Resource using Python and found the CustomObjectsApi documentation unclear. If you have a cluster and a kubeconfig file with a correctly configured current-context, so that you can successfully: PLURAL="checks" kubectl get ${PLURAL} \ --all-namespaces NOTE I’m using Ackal’s CRDs in these examples. Then you can use the following code to access the cluster’s REST API server to enumerate its CRDs: main.py: from __future__ import print_function from kubernetes import client, config from kubernetes.

Thanks to Joe Mooring for his solution to my question as to how to do this. I’ve decided to ditch Google Analytics and am evaluating using GoatCounter with Hugo with Ananke theme. This was the layout of the site: . ├── archetypes ├── content │ └── posts ├── go.mod ├── go.sum ├── hugo.toml ├── layouts ├── public └── static This is the structure (of layouts) with the necessary changes: . ├── archetypes ├── content │ └── posts ├── go.