kube-addon-update.sh

cluster/addons/README.md

+# Cluster add-ons
+
+Cluster add-ons are Services and Replication Controllers (with pods) that are
+shipped with the kubernetes binaries and whose update policy is also consistent
+with the update of kubernetes cluster.
+
+On the clusterm the addons are kept in ```/etc/kubernetes/addons``` on the master node, in yaml files
+(json is not supported at the moment).
+Each add-on must specify the following label: ````kubernetes.io/cluster-service: true````.
+Yaml files that do not define this label will be ignored.
+
+The naming convention for Replication Controllers is
+```<basename>-<version>```, where ```<basename>``` is the same in consecutive
+versions and ```<version>``` changes when the component is updated
+(```<version>``` must not contain ```-```). For instance,
+```heapseter-controller-v1``` and ```heapster-controller-12``` are the
+same controllers with two different versions, while ```heapseter-controller-v1```
+and ```heapster-newcontroller-12``` are treated as two different applications.
+For services it is just ```<basename>``` (with empty version number)
+because we do not expect the service
+name to change in consecutive versions. The naming convetion is important for add-on update.
+
+# Add-on update
+
+To update add-ons, just update the contents of ```/etc/kubernetes/addons```
+directory with the desired definition of add-ons. Then the system will take care
+of:
+
+1. Removing the objects from the API server whose manifest was removed.
+  1. This is done for add-ons in the system that do not have a manifest file with the
+     same basename
+1. Creating objects from new manifests
+  1. This is done for manifests that do not correspond to existing API objects
+     with the same basename
+1. Updating objects whose basename is the samem but whose versions changed.
+  1. The update is currently performed by removing the old object and creating
+     the new one. In the future, rolling update of replication controllers will
+     be implemented to keep the add-on services up and running during update of add-on
+     pods.
+  1. Note that this cannot happen for Services as their version is always empty.
+
+
+
+
+[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/cluster/addons/README.md?pixel)]()

cluster/addons/cluster-monitoring/influxdb/influxdb-service.yaml

@@ -5,6 +5,8 @@ metadata:
   namespace: default 
   labels: 
     k8s-app: influxGrafana
+    kubernetes.io/cluster-service: "true"
+    kubernetes.io/name: "influxGrafana"
 spec: 
   ports: 
     - name: http

cluster/saltbase/salt/kube-addons/init.sls

+addon-dir-delete:
+  file.absent:
+    - name: /etc/kubernetes/addons
+
+addon-dir-create:
+  file.directory:
+    - name: /etc/kubernetes/addons
+    - user: root
+    - group: root
+    - mode: 0755
+    - require:
+        - file: addon-dir-delete
+
 {% if pillar.get('enable_cluster_monitoring', '').lower() == 'influxdb' %}
 /etc/kubernetes/addons/cluster-monitoring/influxdb:
   file.recurse:
@@ -58,6 +71,13 @@
     - group: root
     - mode: 755
 
+/etc/kubernetes/kube-addon-update.sh:
+  file.managed:
+    - source: salt://kube-addons/kube-addon-update.sh
+    - user: root
+    - group: root
+    - mode: 755
+
 {% if grains['os_family'] == 'RedHat' %}
 
 /usr/lib/systemd/system/kube-addons.service:
@@ -77,6 +97,16 @@
 
 {% endif %}
 
+# Stop kube-addons service each time salt is executed, just in case
+# there was a modification of addons.
+# Actually, this should be handled by watching file changes, but
+# somehow it doesn't work.
+service-kube-addon-stop:
+  service.dead:
+    - name: kube-addons
+
 kube-addons:
   service.running:
     - enable: True
+    - require:
+        - service: service-kube-addon-stop

cluster/saltbase/salt/kube-addons/initd

@@ -67,12 +67,7 @@ case "$1" in
         esac
         ;;
   status)
-	    if [ ! -e ${PIDFILE} ]; then
-	        exit 1
-	    fi
-	    pid=$(cat ${PIDFILE})
-        # Checks that ${pid} is running AND is us.
-        ps --no-headers ${pid} | grep ${SCRIPTNAME} > /dev/null || exit $?
+        status_of_proc -p $PIDFILE $KUBE_ADDONS_SH $NAME
         ;;
 
   restart|force-reload)

cluster/saltbase/salt/kube-addons/kube-addons.sh

@@ -81,7 +81,7 @@ function create-resource-from-string() {
   local -r config_string=$1;
   local tries=$2;
   local -r delay=$3;
-  local -r config_name=$1;
+  local -r config_name=$4;
   while [ ${tries} -gt 0 ]; do
     echo "${config_string}" | ${KUBECTL} create -f - && \
         echo "== Successfully started ${config_name} at $(date -Is)" && \
@@ -104,6 +104,7 @@ echo "== Kubernetes addon manager started at $(date -Is) =="
 # at the same time as the services that use them.
 # NOTE: needs to run as root to read this file.
 # Read each line in the csv file of tokens.
+# Expect errors when the script is started again.
 while read line; do
   # Split each line into the token and username.
   IFS=',' read -a parts <<< "${line}"
@@ -120,22 +121,13 @@ for obj in $(find /etc/kubernetes/admission-controls \( -name \*.yaml -o -name \
   echo "++ obj ${obj} is created ++"
 done
 
-for obj in $(find /etc/kubernetes/addons \( -name \*.yaml -o -name \*.json \)); do
-  start_addon ${obj} 100 10 &
-  echo "++ addon ${obj} starting in pid $! ++"
-done
-noerrors="true"
-for pid in $(jobs -p); do
-  wait ${pid} || noerrors="false"
-  echo "++ pid ${pid} complete ++"
+# Check if the configuration has changed recently - in case the user
+# created/updated/deleted the files on the master.
+while true; do
+  #kube-addon-update.sh must be deployed in the same directory as this file
+  `dirname $0`/kube-addon-update.sh /etc/kubernetes/addons
+  sleep 600
 done
-if [ ${noerrors} == "true" ]; then
-  echo "== Kubernetes addon manager completed successfully at $(date -Is) =="
-else
-  echo "== Kubernetes addon manager completed with errors at $(date -Is) =="
-fi
 
-# We stay around so that status checks by salt make it look like
-# the service is good. (We could do this is other ways, but this
-# is simple.)
-sleep infinity
+
+

cluster/saltbase/salt/kube-master-addons/init.sls

@@ -25,6 +25,14 @@
 {% endif %}
 
 # Used to restart kube-master-addons service each time salt is run
+# Actually, it doens't work (the service is not restarted),
+# but master-addon service always terminates after it does it job,
+# so it is (usually) not running and it will be started when
+# salt is run.
+# This salt state is not removed because there is a risk
+# of introducing regression in 1.0. Please remove it afterwards.
+# See also the salt config for kube-addons to see how to restart
+# a service on demand.
 master-docker-image-tags:
   file.touch:
     - name: /srv/pillar/docker-images.sls

cluster/saltbase/salt/kube-master-addons/initd

@@ -67,12 +67,7 @@ case "$1" in
         esac
         ;;
   status)
-	    if [ ! -e ${PIDFILE} ]; then
-	        exit 1
-	    fi
-	    pid=$(cat ${PIDFILE})
-        # Checks that ${pid} is running AND is us.
-        ps --no-headers ${pid} | grep ${SCRIPTNAME} > /dev/null || exit $?
+        status_of_proc -p $PIDFILE $KUBE_MASTER_ADDONS_SH $NAME
         ;;
 
   restart|force-reload)

cluster/saltbase/salt/kube-master-addons/kube-master-addons.sh

@@ -38,3 +38,5 @@ while true; do
 
 done;
 
+# Now exit. After kube-push, salt will notice that the service is down and it
+# will start it and new docker images will be loaded.

cluster/saltbase/salt/logrotate/init.sls

@@ -2,7 +2,7 @@ logrotate:
   pkg:
     - installed
 
-{% set logrotate_files = ['kube-scheduler', 'kube-proxy', 'kubelet', 'kube-apiserver', 'kube-controller-manager'] %}
+{% set logrotate_files = ['kube-scheduler', 'kube-proxy', 'kubelet', 'kube-apiserver', 'kube-controller-manager', 'kube-addons'] %}
 {% for file in logrotate_files %}
 /etc/logrotate.d/{{ file }}:
   file:

cluster/saltbase/salt/monit/init.sls

@@ -30,6 +30,14 @@ monit:
     - mode: 644
 {% endif %}
 
+/etc/monit/conf.d/kube-addons:
+  file:
+    - managed
+    - source: salt://monit/kube-addons
+    - user: root
+    - group: root
+    - mode: 644
+
 /etc/monit/monit_watcher.sh:
   file.managed:
     - source: salt://monit/monit_watcher.sh

cluster/saltbase/salt/monit/kube-addons

+check process kube-addons with pidfile /var/run/kube-addons.pid
+group kube-addons
+start program = "/etc/init.d/kube-addons start"
+stop program = "/etc/init.d/kube-addons stop"
+if does not exist then restart

test/e2e/monitoring.go

@@ -86,7 +86,7 @@ func verifyExpectedRcsExistAndGetExpectedPods(c *client.Client) ([]string, error
 			return nil, err
 		}
 		if len(rcList.Items) != 1 {
-			return nil, fmt.Errorf("expected to find one replicat for RC with label %s but got %d",
+			return nil, fmt.Errorf("expected to find one replica for RC with label %s but got %d",
 				rcLabel, len(rcList.Items))
 		}
 		for _, rc := range rcList.Items {