【Kubernetes】kubeadmで用意したkube-proxyを再起動する

はじめに

kubeadmでインストールした環境ではkube-proxyはPodとして各ノードに展開され、それはデーモンセットで管理されています。
本記事ではkube-proxyに関する情報を実機で確認しながら再起動する流れを整理しました。

環境情報

kubeadm 1.15
kube-proxy 1.15

kube-proxyの作成タイミング

kubeadmでinitを行った際にMasterノードにServiceAccount＆ClusterRole＆ClusterRoleBinding＆ConfigMap＆DaemonSetで起動されます。

具体的にはkubeadmの中で実行されるproxy.goの以下箇所でリソースが作成されます。

ServiceAccount

func CreateServiceAccount(client clientset.Interface) error {
...

ClusterRole/ClusterRoleBindings

func CreateRBACRules(client clientset.Interface) error {
...

ConfigMap

func createKubeProxyConfigMap(cfg *kubeadmapi.ClusterConfiguration, localEndpoint *kubeadmapi.APIEndpoint, client clientset.Interface) error {
...

DaemonSet

func createKubeProxyAddon(cfg *kubeadmapi.ClusterConfiguration, client clientset.Interface) error {
...

kube-proxyのDaemonSetを再起動

作成されたリソースをyamlに吐き出すことで詳細が確認できます。

例えば、kube-proxyのデーモンセットのyamlを表示した結果は以下。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  annotations:
    deprecated.daemonset.template.generation: "1"
  generation: 1
  labels:
    k8s-app: kube-proxy
  name: kube-proxy
  namespace: kube-system
spec:
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: kube-proxy
  template:
    metadata:
      creationTimestamp: null
      labels:
        k8s-app: kube-proxy
    spec:
      containers:
      - command:
        - /usr/local/bin/kube-proxy
        - --config=/var/lib/kube-proxy/config.conf
        - --hostname-override=$(NODE_NAME)
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName
        image: k8s.gcr.io/kube-proxy:v1.15.1
        imagePullPolicy: IfNotPresent
        name: kube-proxy
        resources: {}
        securityContext:
          privileged: true
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /var/lib/kube-proxy
          name: kube-proxy
        - mountPath: /run/xtables.lock
          name: xtables-lock
        - mountPath: /lib/modules
          name: lib-modules
          readOnly: true
      dnsPolicy: ClusterFirst
      hostNetwork: true
      nodeSelector:
        beta.kubernetes.io/os: linux
      priorityClassName: system-node-critical
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      serviceAccount: kube-proxy
      serviceAccountName: kube-proxy
      terminationGracePeriodSeconds: 30
      tolerations:
      - key: CriticalAddonsOnly
        operator: Exists
      - operator: Exists
      volumes:
      - configMap:
          defaultMode: 420
          name: kube-proxy
        name: kube-proxy
      - hostPath:
          path: /run/xtables.lock
          type: FileOrCreate
        name: xtables-lock
      - hostPath:
          path: /lib/modules
          type: ""
        name: lib-modules
  updateStrategy:
    rollingUpdate:
      maxUnavailable: 1
    type: RollingUpdate

上記にある通りでconfigmapを参照しており、そのconfigmapの中でクラスターのIPを動的に管理しています。

 clusters:
    - cluster:
        certificate-authority: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        server: https://X.X.X.X:6443
      name: default
    contexts:

kube-proxyのDaemonsetを停止する

再起動できるようにyamlとして保持した状態で

# kubectl get daemonset.apps/kubeproxy -n kube-system -o=yaml > kubeproxy-ds.yaml

以下で消去すれば

# kubectl delete -f kubeproxy-ds.yaml

全てのPodは各ノードから消去されます。

終わりに

kubeadmではKube-Proxyが初回起動時に自動で生成されますが、「Service」のIPに対して疎通確認ができない場合は同Podの挙動が原因の場合があるため、落とし上げする流れや構成要素は覚えておくと役立ちます。

以上、ご参考になれば幸いです。

(O+P)ut

アウトプット