我有一个可以访问openstack站点来做我的工作的帐户，每次当我要执行任何openstack cli命令时，我必须提供额外的"——不安全"选项使其工作，如下所示:
>> openstack server list --insecure
+--------------------------------------+------------------------------+--------+-----------------------------------------------------+--------------------------+-----------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+------------------------------+--------+-----------------------------------------------------+--------------------------+-----------+
| 57bea5... | US-280-1 | ACTIVE | main_network=10.31.1.162, 10.96.129.112 | N/A (booted from volume) | m1.xlarge |
| 7ace60... | US-280-2 | ACTIVE | main_network=10.31.0.200, 10.96.130.120 | N/A (booted from volume) | m1.xlarge |
无论如何，今天我想通过使用kubespray框架创建一个k8s集群，并且我已经将external_cloud_provider设置为"openstack";太!基本的，我想学习如何做k8s设置。
我已经检查了代码从这个链接，https://github.com/kubernetes-sigs/kubespray，并运行安装没有任何错误。
但是在一切都设置好之后，我要检查pod状态，我看到了一个失败的pod:
>>kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system openstack-cloud-controller-manager-v2qb8 0/1 CrashLoopBackOff 12 (38s ago) 23m
...
在pod日志中，它说:
I1117 00:09:29.487677 1 serving.go:348] Generated self-signed cert in-memory
W1117 00:09:29.642451 1 client_config.go:617] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work.
W1117 00:09:29.642451 1 client_config.go:617] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work.
W1117 00:09:29.668751 1 openstack.go:173] New openstack client created failed with config: Post "http://<my_original_openstack_site>:5000/v3/auth/tokens": x509: certificate signed by unknown authority
F1117 00:09:29.668907 1 main.go:84] Cloud provider could not be initialized: could not init cloud provider "openstack": Post "https://<my_original_openstack_site>:5000/v3/auth/tokens": x509: certificate signed by unknown authority
我有一种感觉我需要设置这个标志&;insecure=true&;在此openstack云提供商设置过程中。有谁知道我应该把这面旗帜放在哪里吗?
谢谢你的帮助。
杰克
服务器证书的客户端验证是导致" x509:证书由未知权威机构签署"的原因。错误。* *
客户端证书由kubecconfig文件中的auth-provider生成，我假设您正在使用Google Cloud，例如:
- name: kubectl-user
user:
auth-provider:
config:
cmd-args: config config-helper --format=json
cmd-path: /usr/lib/google-cloud-sdk/bin/gcloud
expiry-key: '{.credential.token_expiry}'
token-key: '{.credential.access_token}'
name: gcp
如果certificate-authority-data字段缺失或者与k8s API服务器提供的证书的颁发者不同，那么任何需要访问k8s API服务器的kubectl命令都将失败，并显示错误"x509: certificate signed by unknown authority"。
故障排除和缓解步骤:
要检查kubecconfig文件中的CA是否与kube API服务器提供的证书的颁发者具有相同的颁发者，请执行以下步骤。
1)从kubecconfig文件中获取证书:
kubectl config view --minify --raw --output 'jsonpath={..cluster.certificate-authority-data}' |
base64 -d > /tmp/kubectl-cacert
2)获取k8s API服务器提供的证书:
CLUSTER_IP=$(kubectl config view --minify --output 'jsonpath={..cluster.server}' |
cut -d"/" -f3)
if [ -n "${CLUSTER_IP}" ]; then openssl s_client -connect $CLUSTER_IP:443 2>/dev/null </dev/null |
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/kube-api-cacert; else echo 'Cluster IP not set.'; fi
3)检查证书，它们应该具有相同的颁发者:
openssl x509 -in /tmp/kube-api-cacert -issuer -noout
openssl x509 -in /tmp/kubectl-cacert -issuer -noout
示例输出
$ openssl x509 -in /tmp/kube-api-cacert -issuer -noout
issuer=CN = 38d76ff6-cc21-474b-b919-c746d845d03d
$ openssl x509 -in /tmp/kubectl-cacert -issuer -noout
issuer=CN = 38d76ff6-cc21-474b-b919-c746d845d03d
如果发行者不同，您将得到"无法连接到服务器:x509:证书由未知权威签署";错误。可以在kubecconfig中使用来自k8s API服务器的相同证书，kubectl应该可以工作，例如:
kubectl config set clusters.$(kubectl config current-context).certificate-authority-data $(cat /tmp/kube-api-cacert | base64 -w0)
4)运行kubectl应该可以正常工作:
$ kubectl get node
NAME STATUS ROLES AGE VERSION
gke-cert-error-cluster-default-pool-32170571-1f1r Ready <none> 21h v1.21.10-gke.2000
gke-cert-error-cluster-default-pool-32170571-1r6h Ready <none> 21h v1.21.10-gke.2000
gke-cert-error-cluster-default-pool-32170571-4mbj Ready <none> 21h v1.21.10-gke.2000
错误"CrashLoopBackOff">表示Kubernetes状态，表示Pod中正在发生的重启循环:Pod中的一个容器启动了，但是崩溃了，然后重新启动，一次又一次。Kubernetes将在重启之间等待越来越长的后退时间，以给您修复错误的机会。
CrashLoopBackOff的常见原因:
与实际应用程序相关的一些错误如下:
1)这意味着在您的docker映像中有一个错误，容器/POD无法启动。我建议你仔细检查nginx配置文件etc/nginx/conf.d/project.conf是否有任何错误配置。
2)资源不可用:如未挂载的PersistentVolume
3)错误的命令行参数:要么缺少，要么不正确。
4)错误,异常:它可以是任何东西，非常特定于你的应用程序。
最后，来自网络和权限的错误如下:
1)您试图绑定一个已存在的端口。
2)内存限制过低，因此容器被OOM杀死。
3)活性探针中的错误没有报告Pod准备好。
4)只读文件系统，或者缺少权限。
一个类似的回退期是ImagePullBackOff，这是一个等待状态，当容器映像不能被拉出时。以上只是一些可能的原因，但可能还有很多其他的原因。
检查如何调试，故障排除和修复CrashLoopBackOff状态:
1)检查pod描述。
2)检查pod日志
3)检查事件
4)检查部署
请参阅CrashLoopBackOff以及如何修复它以获取更多信息。