songbinliu

Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.

In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.

Creating a Fork

Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j

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	-

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:

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).

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

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";

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

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

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

---
apiVersion: v1
kind: Namespace

#!/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"

	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