Hacky fix for weaveworks/weave#2797

Dockerfile

FROM mirror-hub.docker.tech.lastmile.com/alpine:3.5

RUN apk add --no-cache curl jq

RUN curl -o /usr/local/bin/kubectl https://storage.googleapis.com/kubernetes-release/release/v1.5.3/bin/linux/amd64/kubectl && chmod +x /usr/local/bin/kubectl

COPY rmpeers /

CMD ["/rmpeers"]

rmpeers

#!/bin/sh

set -e
set -u
set -x

while true; do
  curl -H "Accept: application/json" http://localhost:6784/report | jq -r .IPAM.Entries[].Nickname > /tmp/nicknames
  kubectl get node -o custom-columns=name:.metadata.name --no-headers > /tmp/node-names
  grep -v -f /tmp/node-names /tmp/nicknames | xargs -n 1 -I '{}' curl -H "Accept: application/json" -X DELETE 'http://localhost:6784/peer/{}'
  sleep 60
done

weave-net-rmpeers.yaml

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: weave-net-rmpeers
  namespace: kube-system
spec:
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: weave-net-rmpeers
    spec:
      containers:
      - name: rmpeers
        image: hub.docker.tech.lastmile.com/mikebryant/rmpeers:v6
        resources:
          requests:
            cpu: "0.01"
            memory: "20Mi"
          limits:
            cpu: "0.1"
            memory: "20Mi"
        volumeMounts:
        - name: fence
          mountPath: /unused
      hostNetwork: true
      volumes:
      - name: fence
        persistentVolumeClaim:
          claimName: weave-net-rmpeers-fence
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: weave-net-rmpeers-fence
  namespace: kube-system
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

So we used this successfully for a long time and ran into a very interesting case today. Our cluster API was unreachable due to some general networking issue so the kubectl get node -o custom-columns=name:.metadata.name --no-headers > /tmp/node-names failed.

This resulted in the script essentially thinking there were no nodes in the cluster and promptly deleting them all. Adding in a set -o pipefail at the top of the script would abend the loop and exit so that the script would not attempt to delete all of the Weave peers in the cluster, which is what happened to us.