songbinliu

Workload Prediction

#!/bin/bash

echo "SOURCE_COMMIT: $SOURCE_COMMIT"

if [[ -z "$SOURCE_COMMIT" ]]; then
	export SOURCE_COMMIT="${SOURCE_COMMIT:-$(git rev-parse HEAD)}"
	echo "Updating SOURCE_COMMIT from git rev-parse HEAD"

the all-in-one yaml file for deploying kubeturbo. Dry run

kubectl --dry-run=true apply -f all.yaml

---
apiVersion: v1
kind: Namespace

Using git to prepare your PR to have a clean history

This article is copied from mockito

Tests in any project are a valuable asset, so is a clean version history. Having a proper and clean commits helps to review and understand changes. Git is an awesome tool that let you control how you want your history. GitHub just use the history of the branch, so each time the history is changed the PR is updated with the actual history. GitHub PR is a fantastic way to have changes review before merge.

The following tips may help you if you are not proficient in git, but they consists hardly in a bullet proof tutorial, knowing git is the most bullet proof skill. But the steps of the following options can guide you to have a clean history.

There are multiple blog entries explaining git, I find the following two quite compelling and showing a modern way to do things right in git, of course [StackOverflow](http://stackov

Experiment about Kubernetes scheduling policy

Kubernetes 1.6 offers some advanced scheduling features, including cutomer scheduler. User can set schedulerName when creating new Pod. Before reading the code of Kubernetes ApiServer and kubelete, some tests are done to have a initial understanding of Kubernetes scheduling policies.

Different situations

This experiments will test the behaviour of Pod scheduluation in different situations:

1. create a Pod without setting the schedulerName;
1. create a Pod with schedulerName to "default-scheduler";

Move Pod

OpsMgr always wants to move the pod to achieve desired state. But currently, Kubernetes does not offer an API to move a Pod.

So we use a Copy--Delete--Create method to implement the Move operation, by calling Kubernetes APIserver.

Binding-on-Creation

In the Copy-Kill-Create method, before the third step "Create", we assign the new destination host NodeName for the new pod: Pod.Spec.NodeName, so the new Pod will be binded to that desired host directly, without the necessary to wait

Kubernetes SharedInformer

Overview

SharedInformer has a shared data cache, and is able to distribute notifications for changes to the cache to multiple listeners who have registered to it. SharedInformer is also a "Producer-Consumer" framework, using Controller as Producer to produce the Events (, or changes to the cache).

Kubernetes Reflector

Reflector is a key component for Kubernetes clients, kube-scheduler and Replication Controller. Reflector is in the middle between client and Kubernetes API-server. It provides a framework to monitor the changes of the Kubernetes cluster.

Definition of Reflector

Here is the definition of Reflector.

As shown in the definition, there are two important compoents of a Reflector:

Node Affinity/anti-Affinity

Type	description	supported	date
equal	Node[Key] = value	Yes	2017.03.01
In	Node[Key] IN [v1, v2 …]	No	-
NotIn	Node[Key] NotIn [v1, v2, …]	No	-
Exists	Node.Key Exists	Yes	-
DoesNotExists	Node.Key DoesNotExists	No	-
Gt	Node[Key] Greater than Value	No	-

	language: go

	# Only the last two Go releases are supported by the Go team with security
	# updates. Any versions older than that should be considered deprecated.
	# Don't bother testing with them. tip builds your code with the latest
	# development version of Go. This can warn you that your code will break
	# in the next version of Go. Don't worry! Later we declare that test runs
	# are allowed to fail on Go tip.
	go:
	- 1.9