duxing

Context

Due to a lack of control plane observability, I recently re-integrated Datadog helm chart on our kops-provisioned k8s cluster. kops is definitely not the most popular k8s solution and the official control plane monitoring guide doesn't cover detailed steps.

Throughout the process, I ran into one major issue (details later), potentially caused by compatibility between kops and datadog-agent. Investigation kept me busy, and I still don't have a definitely answer to "fix" it. However, I came up with a solution to bypass this issue to ensure full visibility coverage for the control plane.

Overview

A k8s control plane has 4 major components:

• kube-api-server

duxing

I ran into a weird issue while setting up a docker image:

• the image was based on alpine and has kubectl and awscli installed
• both aws credentials (~/.aws/credentials) and kube config(~/.kube/config) are mounted to the container
  • the command for docker looks like: docker run -it --rm -v ${HOME}/.aws:/root/.aws -v ${HOME}/.kube:/root/.kube <my_image> /bin/bash
• my laptop is connected to VPN and my k8s cluster is on a VPC accessible only via VPN.

What I observed:

• on the host (my laptop):
  • both aws and kubectl calls are successful.
• in the container:

duxing

I've been assessing HikariCP as a replacement for BoneCP for my server in the past week, and the result is somewhat surprising to me.
Sharing it here in case other people were doing the same thing.

The short conclusion is: BoneCP is slightly faster than HikariCP.

Test environment:
 - BoneCP version: 0.8.0-RELEASE
 - HikariCP version: 2.6.1
 - Tested on 2 groups of servers located on Amazon AWS, with DB servers in the same availability zone.
 - The only difference in the version of jar deployed is the connection pooling library difference (as well as the configuration difference)