Ist dies ein FEHLERBERICHT oder eine FEATURE-ANFRAGE? :
/ freundlicher Fehler
Was ist passiert :
Ich habe versucht, einen Cluster mit dem kubeadm
Tool mit aktivierter ABAC-Autorisierung zu erstellen, wobei die folgenden Konfigurationsdateien verwendet wurden.
~/config.yaml
apiVersion: kubeadm.k8s.io/v1alpha1
kind: MasterConfiguration
networking:
podSubnet: 10.244.0.0/16
authorizationModes:
- Node
- RBAC
- ABAC
apiServerExtraArgs:
basic-auth-file: /etc/kubernetes/basic_auth.csv
authorization-policy-file: /etc/kubernetes/abac_policy.json
~/basic_auth.csv
admin,admin,1,"system:masters"
~/abac_policy.json
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"*", "nonResourcePath": "*", "readonly": true}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"admin", "namespace": "*", "resource": "*", "apiGroup": "*"}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group":"system:serviceaccounts", "namespace": "*", "resource": "*", "apiGroup": "*", "nonResourcePath": "*"}}
Der Befehl kubeadm
hängt mit der folgenden Ausgabe...
[init] Using Kubernetes version: v1.9.3
[init] Using Authorization modes: [Node RBAC ABAC]
[preflight] Running pre-flight checks.
[WARNING FileExisting-crictl]: crictl not found in system path
[preflight] Starting the kubelet service
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [k8s-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [####### #######]
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated sa key and public key.
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] Waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests".
[init] This might take a minute or longer if the control plane images have to be pulled.
Es sieht so aus, als ob der kube-apiserver
Container ständig neu gestartet wird.
Die Protokollausgabe aus dem kube-apiserver
Container ergibt
I0306 12:39:33.179719 1 server.go:121] Version: v1.9.3
invalid authentication config: open /etc/kubernetes/basic_auth.csv: no such file or directory
Was Sie erwartet haben, zu passieren :
Ich habe erwartet, dass die kube-apiserver
beginnen.
So reproduzieren Sie es (so minimal und genau wie möglich) :
mkdir -p /etc/kubernetes
cp ~/basic_auth.csv /etc/kubernetes
cp ~/abac_policy.json /etc/kubernetes
kubeadm init --config ~/config.yaml
Müssen wir noch etwas wissen? :
Umgebung :
kubectl version
): v1.9.3uname -a
): Linux k8s-master 4.4.0-116-generic #140-Ubuntu SMP Mo Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/LinuxEs scheint, dass die Dateien /etc/kubernetes/basic_auth.csv
und /etc/kubernetes/abac_policy.json
möglicherweise nicht im Container kube-apiserver
gemountet sind.
Ich habe versucht, die folgende zusätzliche Volume-Strophe zu verwenden, aber ich konnte es nicht mit Dateien zum Laufen bringen, es scheint nur mit Verzeichnissen zu funktionieren.
apiServerExtraVolumes:
- name: <value|string>
hostPath: <value|string>
mountPath: <value|string>
Wenn ich versuche, ein Verzeichnis mit den beiden Dateien zu mounten und die neuen Speicherorte in der Konfiguration angebe, sucht es immer noch am Standardspeicherort! Siehe das generierte /etc/kubernetes/manifests/kube-apiserver.yaml
unten, es hat zwei Einträge für die Option --authorization-policy-file
, der zweite überschreibt scheinbar den ersten.
apiVersion: v1
kind: Pod
metadata:
annotations:
scheduler.alpha.kubernetes.io/critical-pod: ""
creationTimestamp: null
labels:
component: kube-apiserver
tier: control-plane
name: kube-apiserver
namespace: kube-system
spec:
containers:
- command:
- kube-apiserver
- --authorization-policy-file=/etc/kubernetes/users/abac_policy.json
- --basic-auth-file=/etc/kubernetes/users/basic_auth.csv
- --service-account-key-file=/etc/kubernetes/pki/sa.pub
- --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
- --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
- --admission-control=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,ResourceQuota
- --enable-bootstrap-token-auth=true
- --allow-privileged=true
- --requestheader-group-headers=X-Remote-Group
- --advertise-address=#######
- --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
- --insecure-port=0
- --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
- --requestheader-extra-headers-prefix=X-Remote-Extra-
- --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
- --secure-port=6443
- --requestheader-username-headers=X-Remote-User
- --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
- --requestheader-allowed-names=front-proxy-client
- --service-cluster-ip-range=10.96.0.0/12
- --client-ca-file=/etc/kubernetes/pki/ca.crt
- --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
- --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
- --authorization-policy-file=/etc/kubernetes/abac_policy.json
- --authorization-mode=Node,RBAC,ABAC
- --etcd-servers=http://127.0.0.1:2379
image: gcr.io/google_containers/kube-apiserver-amd64:v1.9.3
livenessProbe:
failureThreshold: 8
httpGet:
host: #######
path: /healthz
port: 6443
scheme: HTTPS
initialDelaySeconds: 15
timeoutSeconds: 15
name: kube-apiserver
resources:
requests:
cpu: 250m
volumeMounts:
- mountPath: /etc/kubernetes/pki
name: k8s-certs
readOnly: true
- mountPath: /etc/ssl/certs
name: ca-certs
readOnly: true
- mountPath: /etc/kubernetes/users
name: users
readOnly: true
hostNetwork: true
volumes:
- hostPath:
path: /etc/kubernetes/pki
type: DirectoryOrCreate
name: k8s-certs
- hostPath:
path: /etc/ssl/certs
type: DirectoryOrCreate
name: ca-certs
- hostPath:
path: /etc/kubernetes/users
type: DirectoryOrCreate
name: users
status: {}
@msnelling - Wir Überschreibungsproblem aus .
Eröffnen Sie nach Möglichkeit Probleme mit dem https://github.com/kubernetes/kubeadm-Repository .
Hilfreichster Kommentar
Es scheint, dass die Dateien
/etc/kubernetes/basic_auth.csv
und/etc/kubernetes/abac_policy.json
möglicherweise nicht im Containerkube-apiserver
gemountet sind.Ich habe versucht, die folgende zusätzliche Volume-Strophe zu verwenden, aber ich konnte es nicht mit Dateien zum Laufen bringen, es scheint nur mit Verzeichnissen zu funktionieren.
Wenn ich versuche, ein Verzeichnis mit den beiden Dateien zu mounten und die neuen Speicherorte in der Konfiguration angebe, sucht es immer noch am Standardspeicherort! Siehe das generierte
/etc/kubernetes/manifests/kube-apiserver.yaml
unten, es hat zwei Einträge für die Option--authorization-policy-file
, der zweite überschreibt scheinbar den ersten.