K8s notes

After docker gets installed, it is better to have the regular user be able to do docker command.

sudo gpasswd -a $USER docker

The above command will grant the current user docker permission.

This is the command to pull docker image from gcr.io

docker pull gcr.io/google-containers/hyperkube:v1.9.1

The above command will pull the hyperkube image version v1.9.1 onto your docker environment.

K8S release web site:

https://github.com/kubernetes/kubernetes/releases

It seems that k8s has recommended the following:

run as native services:
  docker, kubelet, and kube-proxy

run as containers:
  etcd, kube-apiserver, kube-controller-manager, and kube-scheduler

hyperkube is a super image which contains kubelet, kube-proxy, kube-controller-manager and kube-scheduler.

You will run docker, kubelet, and kube-proxy outside of a container, the same way you would run any system daemon, so you just need the bare binaries. For etcd, kube-apiserver, kube-controller-manager, and kube-scheduler, we recommend that you run these as containers, so you need the hyperkube image.

Things needed for setting up k8s

etcd:

gcr.io/google-containers/etcd:2.2.1 or
quay.io/coreos/etcd:v2.2.1 

 
k8s:     

gcr.io/google-containers/hyperkube:v1.9.1
BIN_SITE=https://storage.googleapis.com/kubernetes-release/release/
$BIN_SITE/v1.9.1/bin/linux/amd64/kubelet
$BIN_SITE/v1.9.1/bin/linux/amd64/kube-proxy

cloud-config script to set hostname in openstack cloud

#cloud-config
runcmd:
 - addr=$(ip -4 -o addr|grep -v '127.0.0.1'|awk '{print $4}'|cut -d '/' -f 1)
 - echo $addr `hostname` >> /etc/hosts

How to setup docker swarm like env using weave net

The procedure to setup docker swarm on two nodes using weave net

Create two VirtualBox Ubuntu VMs with the following settings:

1. Host-only network and NAT network
2. Each machine resolves the two hosts to their NAT IP addresses
3. Two machines can ping each other using host name

Install docker on each machine:

sudo apt-get install docker.io

Download weave net and make it executable on each machine:

sudo curl -L git.io/weave -o /usr/local/bin/weave
sudo chmod a+x /usr/local/bin/weave

On the first machine(u1710-1), run the following commands:

weave launch
eval $(weave env)

On the second machien(u1710-2), run the following commands:

weave launch u1710-1
eval $(weave env)

Use the follow procedure to test containers running on two machines can talk to each other

1. Start a container on the first machine by running the following command:

docker run --name box1 -it --rm busybox

2. Start a container on the second machine by running the following command, then ping first container:

docker run --name box2 -it --rm busybox
# ping -c2 box1

If one container can ping the other, then you have successfully setup weave net. The containers that you created should be able to ping outside of the world as well.


Note:
1. If you restart your machine, you will need to always run the following command before you start any new container, this is to make sure that your DOCKER_HOST environment varilable gets setup correctly.
2. The procedure has been also tested on aws and openstack cloud. Using the free tier VMs, you will be able to do the same as you do on VirtualBox. If you do this in your cloud environment, the security group will need to include rules to allow port on TCP 6783 and UDP 6783/6784, and TCP 6782 (monitoring) to be open. Of course, it will be also helpful if you allow ICMP traffic and ssh (22) so that you can easily test your connectivity.

Fabric Events

The first thing to note is that nothing happens until a transaction fails or is committed into a block.

If you are listening to a peer for transaction notifications, you will get a success or failure event for the transaction when the following occur:

∑      If the transaction fails during endorsement (i.e. returns an error code), then there will be no read / write set and no transaction ID and the error will be propagated directly to applications listening to the endorser.

∑      If the transaction fails during commit (a.k.a. late failure, MVCC error) because of key version issues, then the block will contain the transaction but without the failure information, so you must be listening for transaction errors to catch these. The world state changes will not have been applied, and you will get the error when the block is written (I believe) to the channel on the peer to which you are listening.

∑      If the transaction is successful and committed to a block, then you will receive a success event when the block has been written into the channel on the peer to which you are listening.

If you are listening for block events, then you will get the event when a block has been written to the channel on the peer to which you are listening.

Chaincode events (a.k.a. contract emitted events) are sent when the block has been written to the channel on the peer to which you are listening. I.e. only when the block is cast in stone do the events come flying out.

If you examine the block format, you will find arrays in there for the transactions, and in each transaction all emitted events are shown (you can emit more than one).

Ubuntu 17.04 and 17.10 network wait on start up issue

systemctl disable systemd-networkd-wait-online.service
systemctl mask systemd-networkd-wait-online.service

After disabling service will still start. Need to mask it

Istanbul BFT

Istanbul BFT inherits from the original PBFT by using 3-phase consensus, PRE-PREPARE, PREPARE, and COMMIT. The system can tolerate at most of F faulty nodes in a N validator nodes network, where N = 3F + 1. Before each round, the validators will pick one of them as the proposer, by default, in a round robin fashion.

The proposer will then propose a new block proposal and broadcast it along with the PRE-PREPARE message.

Upon receiving the PRE-PREPARE message from the proposer, validators enter the state of PRE-PREPARED and then broadcast PREPARE message. This step is to make sure all validators are working on the same sequence and the same round.

While receiving 2F + 1 of PREPARE messages, the validator enters the state of PREPARED and then broadcasts COMMIT message. This step is to inform its peers that it accepts the proposed block and is going to insert the block to the chain.

Lastly, validators wait for 2F + 1 of COMMIT messages to enter COMMITTED state and then insert the block to the chain.

DAG

Terms that matter

Weight (Own weight): The weight of transaction A is proportional to the effort put in by its issuer, which can be assumed to be 3^n.

Cumulative weight: Transaction A’s own weight + the sum of own weights of all the followed transactions that directly/indirectly approve transaction A. (E.g. In figure 4, transaction D has own weight as 1, and cumulative weight as 6 = D’s own weight + A’s own weight + B’ own weight + C’s own weight = 1 + 1 + 3 + 1.)

 

 

 

 

 

 

Figure 4: Weights (from IOTA white paper). Own weights at right-bottom. Cumulative weights at left-top, as bold.

Score: Transaction A’s own weight + the sum of own weights of all previous transactions approved by transaction A. (E.g. In figure 5, transaction A has score as 9 = A’s own weight + B’s own weight + D’s own weight + F’s own weight + G’s own weight = 1 + 3 + 1 + 3 + 1.)

 

 

 

Figure 5: Score (from IOTA white paper). Score at left-top, in the circle.

Height: The length of the longest oriented path to the genesis.

Depth: The length of the longest reverse-oriented oath to certain tips.

For instance, in figure 5, the height of D is 3 (D → F → G → genesis), and the depth of D is 2 (D ← B ← A).