K
Q

Getting running config for kube master components from active cluster

8/6/2019

We have a kube cluster with 5 masters and 50 worker nodes. The kube cluster is running on bare-metal server, not as containers. During the cluster initialization, we update the parameters for the kube-api-server/scheduler/controller as required for our environment, but not all options. Like for a node, we can get the current applied kubelet configs using the API - :/api/v1/nodes//proxy/configz, is there a way to get the current configs (like kube-api-qps, kube-api-burst etc) for the master components (controller, scheduler).

I could get the metrics and healthz for controller and scheduler on 10252 and 10251. However, I could not find how to get the current config for these components via an API.

-- pravege
controller
kubernetes

Similar Questions

kubectl: get specific value from a secret in plaintext
Replicate docker-compose volume behavior in kubernetes
Network policy not working for daemonsets
Kubernetes Template UML models
Two endponts into one service with Kubernetes Nginx Ingress

2 Answers

8/6/2019

The control plane resource files will be stored on /etc/kubernetes/manifests directory. You can look at the configuration of those components from there.

Or You can run below command to get the output from running pods.

   kubectl -n kube-system get <pod name> -o yaml
-- Subramanian Manickam
Source: StackOverflow
8/6/2019

Not from the API (As of this writing) Typically the component configs are passed in through the command line or/and a Pod YAML manifest file. Typically, the manifest files are under /etc/kubernetes/manifests

  • kube-apisever -> /etc/kubernetes/manifests/kube-apiserver.yaml
  • kube-controller-manager -> /etc/kubernetes/manifests/kube-apiserver.yaml
  • kube-scheduler -> /etc/kubernetes/manifests/kube-scheduler.yaml

For example, minikube kube-apiserver:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=192.168.64.6
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/var/lib/minikube/certs/ca.crt
    - --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota
    - --enable-bootstrap-token-auth=true
    - --etcd-cafile=/var/lib/minikube/certs/etcd/ca.crt
    - --etcd-certfile=/var/lib/minikube/certs/apiserver-etcd-client.crt
    - --etcd-keyfile=/var/lib/minikube/certs/apiserver-etcd-client.key
    - --etcd-servers=https://127.0.0.1:2379
    - --insecure-port=0
    - --kubelet-client-certificate=/var/lib/minikube/certs/apiserver-kubelet-client.crt
    - --kubelet-client-key=/var/lib/minikube/certs/apiserver-kubelet-client.key
    - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
    ...

The kube-proxy is a bit different.

  • kube-proxy -> kube-proxy ConfigMap YAML in the kube-system namespace

To get a sense of what you can do with the API you can use the kubectl get --raw command. For example:

$ kubectl get --raw /
{
  "paths": [
    "/api",
    "/api/v1",
    "/apis",
    "/apis/",
    "/apis/admissionregistration.k8s.io",
    "/apis/admissionregistration.k8s.io/v1beta1",
    "/apis/apiextensions.k8s.io",
    "/apis/apiextensions.k8s.io/v1beta1",
    "/apis/apiregistration.k8s.io",
    "/apis/apiregistration.k8s.io/v1",
    ...
-- Rico
Source: StackOverflow