Issue 1:
Process for bringing up an etcd cluster in a PetSet (minimal requirements). Some discussion of races and inconsistencies.

https://coreos.com/etcd/docs/latest/clustering.html

https://coreos.com/etcd/docs/latest/runtime-configuration.html

Initialization (option1)

Decide on a unique --initial-cluster-token and ensure that will be every pod as an ENV var (could be the petset UID or a simple parameter value)

Create all pods and unique PVs for each

Wait for all endpoints to be reachable to reflect all pods (requires we either know the quorum size, or know that the pet set has reached desired size). Pods won't be ready, so we need to wait for ready+unready endpoints to == quorum size

etcd process starts with the initial bootstrap args (knowing what other members are in the set)

After this, no dynamic reconfiguration is allowed.

Initialization (option2)

Decide on a unique --initial-cluster-token and ensure that will be every pod as an ENV var (could be the petset UID or a simple parameter value)

Have the pod that gets identity "1" (or "master", or "first") create a new cluster

Have a control loop (babysitter / etc) running with pod identity 1 that tries to keep the cluster membership up to date with the endpoints list in etcd.

This allows dynamic reconfiguration, but is subject to duplicate instances of the babysitter running (discussed below). It is possible to write the babysitter so that cluster membership always moves forward, but not possible to guarantee that two babysitters aren't running at the same time.

Dealing with duplicate members without PV to act as a lock

It is possible that a kubelet becomes isolated from the cluster while running member 1 of a 3 pod set, and etcd is not configured to use PV (which acts as a form of lock in some cases). The node controller detects that the kubelet is dead and triggers deletion of those pods. After graceful deletion elapses, a new pod with member 3 will be created. At this point, there are potentially two member-1's running.

In option2 above, there could be two control loops running at the same time, and different pods could also see different endpoint versions (so the separated pod could see the older endpoint list).

In option1 above, the kubelet could get isolated during initialization, and two instances of member-1 could be started. Both would initialize, and the control loops in each would try to acquire members. If sufficiently large numbers of nodes experienced partition, both sides could think they had a quorum.

The resolution is to require the babysitters to make a write to the master API in a way that collapses one side or the other (such as writing to the endpoints).

Upgrade (normal)

Are all members healthy with a quorum?

Backup each member PV

Ensure clean shutdown of members on old version up to floor(N / 2), to leave a quorum running

Start a new pod with the same PV as the old pod

During upgrade the same membership problems become possible as during initialization. As long as the set has a quorum, it can police it's own membership, but a disruptive event during upgrade that disables quorum means that the babysitters would have to write to the master API in a similar way as during initialization.

Upgrade (disaster)

In a disaster scenario, a majority of the PVs in the etcd cluster are lost. No quorum is possible, but again a babysitter can rely on the external master API to resolve leadership for a period of time and reestablish quorum and ensure that the new members join the appropriate quorum.

Thoughts

Even though etcd has its own consistent mechanism for managing membership, that requires a quorum. Since the babysitter is itself potentially distributed, it must obtain a lease / lock to change membership in a strongly consistent fashion. Only membership changes (pod creation / deletion, endpoint changes) require the babysitter to act in this fashion. The remainder of the time, etcd can manage its own quorum state.

If membership changes are relatively rare, there could be advantages to viewing the babysitter as a "cluster change hook". The babysitter could be a run-once pod with a long duration grace period (lease, effectively) that is invoked on cluster membership changes, and the name of the pod could act as the lease (since writes to the master API are strongly consistent). If the node running the babysitter goes down, it's possible to break the lock by deleting the pod forcefully with the corresponding lack of control over the outcome of any code still running in the pod.

A one shot pod on membership changes has some advantages - limited resource consumption for the stability of the pod, easier potentially to reason about.

Issue 2:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.):

No

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.):

dnsmasq log

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

FEATURE REQUEST

Kubernetes version (use kubectl version):

1.3.4

Environment:

Cloud provider or hardware configuration: bare-metal

OS (e.g. from /etc/os-release): CoreOS 1068.8.0

Kernel (e.g. uname -a): Linux $REDACTED 4.6.3-coreos #2 SMP Mon Jul 18 06:10:39 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5530 @ 2.40GHz GenuineIntel GNU/Linux

Install tools: bootcfg and ignition

Others:

What happened:

I started kube-dns according to this example: https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/skydns-rc.yaml.base

kubectl logs --tail=100 -f kube-dns-v19-????? dnsmasq did not show anything.

What you expected to happen:

kubectl logs --tail=100 -f kube-dns-v19-????? dnsmasq should have shown log messages. There should have been at least a start-up message and it should possibly also log DNS requests, as does the kubedns container.

How to reproduce it (as minimally and precisely as possible):

Take the example kube-dns-rc.yaml and create a resource controller from it.

Anything else do we need to know:

For my DHCP/TFTP dnsmasq pod these command line switches have the desired effect: --keep-in-foreground --log-facility=-