A recent task had me taking a look at alternative JSON libraries for the purpose of performance. One of them was python-rapidjson which offered support for SIMD.

Compiling

To get python-rapidjson to compile with SIMD, we need to define one of the SIMD macros, either RAPIDJSON_SSE2, RAPIDJSON_SSE42, or RAPIDJSON_NEON.

The chosen flag would then need to be passed to pip during install via CFLAGS. Depending on the flag, you would have to pass some addition options.

• SSE2: CFLAGS="-DRAPIDJSON_SSE2=1"
• SSE4.2: CFLAGS="-DRAPIDJSON_SSE42=1 -msse4.2"

One-liner to re-install the currently installed version as the SIMD version.

CFLAGS="-DRAPIDJSON_SSE42=1 -msse4.2" pip -v install -force-reinstall -no-binary python-rapidjson $(pip freeze | grep python-rapidjson)

Many popular apps offer live stream as a feature integration like Twitch and Youtube Live. With the ever increasing users drawn towards video based services, as seen with the trending race to top Youtube subscribed, the technology behind video delivery is equally increasing in importance. While most service will integrate video as a VOD like much of Youtube or DouYin, the challenge lies with live video delivery.

So what’s available?

There are many solutions available and is dependent on use case, but there are mainly 2 options, RTMP and DASH/HLS. While HLS is an option and having the much larger market share compared to DASH, DASH is vastly superior in terms of feature offering with DASH being able to support the majority of features of HLS. …

To use XFS with Persistent Volumes, the host node needs to have the command xfs_mkfile available so disks can be created and formatted. The problem comes when needing to do this on GKE where there are 2 OSs available, ubuntu which has xfsprogs installed by default and cos which does not. Also, before ubuntu was available, container-vm was the used for XFS, but required a separate install.

The solution I took was to add a XFS support node label at node pool creation time using OS image ubuntu. While this sort of works, there are a couple problems.

• The need to remember to add a XFS node label when creating a new node…

I’ve recently needed to revisit some of our deployments which were created in the earlier days of GKE where some useful features were not available. One component revisited was the disabling the kernel setting Transparent Huge Pages (THP) recommended for mongo and redis.

The solution at the time was to use a Daemonset running a startup script with gcr.io/google-containers/startup-script:v1.

There are a couple of areas that could be improved

• hostPID and securityContext seemed excessive
• No checks if the setting actually changed
• gcr.io/google-containers/startup-script:v1 is a relatively large image
• Timing conflicts with pod scheduling

hostPID and securityContext

Instead of using hostPID and priviledged: true, we can mount the host’s /sysinto the pod as a volume. …

tl;dr Use empty volume, initContainers, and subPath to copy and mount kubectl.

The Why

I needed access to the kubernetes API from within a pod so that the pod can self label itself.

For example, I am currently working with redis and redis-sentinel. When sentinel triggers a reconfigure script, I want the pod to re-label itself to role=masteror role=slave. I didn’t want to create a custom redis image that includes kubectl as it would be another component to maintain.

Also, what if I needed to work with other images requiring kubectl? Seemed like alot of maintenance going the custom image route.

The How

First, create an empty volume to hold the kubectl binary. …

There are some situations where you just need to run a simple single command cronjob. This is where the alpineDocker image comes in very handy. It comes with a simple yet flexible cron package via busybox.

Single Line

For very simple stuff, a single command using the default alpine image.

Mounted Volume

For more complex crontabs, mount a crontab file!

Compiled Docker Image

Compiling your own image with an entrypoint makes it cleaner to run.

Update Sept 6 2017: As of Aug 8 2017, GKE has released the ubuntu image to replace container-vm. This image has xfsprogs pre-installed. Use this instead.

We had a mongo replicaset cluster setup in Google Container Engine that was using the default ext filesystem when creating PersistentVolumes. The recommendation by mongo is that the xfsshould be used instead.

1. The default image on GKE is gci, based on ChromiumOS, which does not have a straightforward method for installing packages for xfs.
2. container-vm does have xfsprogs, but is not installed by default
3. Custom images are not supported on GKE.
4. There’s no standard/recommended method for running node startup scripts. …