标签: kubernetes-apiserver

我正在尝试使用kubeadm此处记录的Azure在Azure中创建HA Kubernetes集群https://kubernetes.io/docs/setup/independent/high-availability/

当只使用1个主节点时我可以正常工作但是当更改为3个主节点时,kube-dns会随着apiserver问题而崩溃

我可以看到运行时kubectl get nodes3个主节点已准备就绪

NAME           STATUS    ROLES     AGE       VERSION
k8s-master-0   Ready     master    3h        v1.9.3
k8s-master-1   Ready     master    3h        v1.9.3
k8s-master-2   Ready     master    3h        v1.9.3

但是dns和仪表板吊舱一直在崩溃

NAME                                    READY     STATUS             RESTARTS   AGE
kube-apiserver-k8s-master-0             1/1       Running            0          3h
kube-apiserver-k8s-master-1             1/1       Running            0          2h
kube-apiserver-k8s-master-2             1/1       Running            0          3h
kube-controller-manager-k8s-master-0    1/1       Running            0          3h
kube-controller-manager-k8s-master-1    1/1       Running            0          3h
kube-controller-manager-k8s-master-2    1/1       Running            0          3h
kube-dns-6f4fd4bdf-rmqbf                1/3       CrashLoopBackOff   88         3h
kube-proxy-5phhf                        1/1       Running            0          3h
kube-proxy-h5rk8                        1/1       Running …

我们的Kubernetes 1.6集群具有在2017年4月13日构建集群时生成的证书。

2017年12月13日，我们的集群升级到了版本1.8，并生成了新证书[显然，证书集不完整]。

从2018年4月13日起，我们开始在api服务器的Kubernetes仪表板中看到以下消息：

[authentication.go:64] Unable to authenticate the request due to an error: [x509: certificate has expired or is not yet valid, x509: certificate has expired or is not yet valid]

试图指向客户端证书和客户端密钥内/etc/kubernetes/kubelet.conf，在上12月13日[生成的证书apiserver-kubelet-client.crt和apiserver-kubelet-client.crt]，但继续看到上述错误。

试图指向客户端证书和客户端密钥内/etc/kubernetes/kubelet.conf，在不同的12月13日[生成的证书apiserver.crt和apiserver.crt（I真的不理解这些2台证书/密钥之间的差），但是继续看到上述错误。

试图指向客户端证书和客户端密钥中/etc/kubernetes/kubelet.conf的不存在的文件，并没有KUBE的*服务将启动，有/var/log/syslog抱怨这一点：

Apr 17 17:50:08 kuber01 kubelet[2422]: W0417 17:50:08.181326 2422 server.go:381] invalid kubeconfig: invalid configuration: [unable to …

我正在使用kubectl和--dry-run遇到奇怪的行为。

为简化起见，假设我具有以下yaml文件：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    run: nginx
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      run: nginx
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        run: nginx
    spec:
      containers:
      - image: nginxsdf
        imagePullPolicy: Always
        name: nginx

修改例如图像或副本数：

• kubectl apply -f Deployment.yaml -o yaml --dry-run向我输出具有OLD规范的资源

• kubectl apply -f Deployment.yaml -o yaml向我输出具有新规范的资源

根据文档：

--dry-run = false：如果为true，则仅打印将要发送的对象，而不发送它。

但是，打印的对象是旧对象，而不是将被发送到ApiServer的对象。

在minikube，gke v1.10.0上测试

同时，我为此打开了一个新的gitHub问题：

• https://github.com/kubernetes/kubernetes/issues/72644

我正在使用KubeSpray在 AWS 上配置一个两节点集群。默认情况下--kubelet-certificate-authority不使用该参数。不过，我想设置一下。

我不知道 的正确设置--kubelet-certificate-authority。当我将其设置为时，/etc/kubernetes/pki/ca.crt我会在日志中看到如下消息：

TLS handshake error from 10.245.207.223:59278: remote error: tls: unknown certificate authority

为了创建一个隔离的测试环境，我通过 SSH 连接到我的控制器节点来运行此命令，该命令在4667. 我直接从 复制这些值/etc/kubernetes/manifests/kube-apiserver.yaml。您需要调整该值以匹配您自己的集群。我特意以交互模式运行容器，以便可以看到日志消息。

TLS handshake error from 10.245.207.223:59278: remote error: tls: unknown certificate authority

现在可以再次通过 SSH 连接到控制器并用于curl与自定义 apiserver 容器进行交互。

• 将 APISERVER 变量设置为指向控制器节点。我正在使用上面参数的值advertise-address。

APISERVER=https://10.245.207.223:6447

• 获得一个令牌。

sudo docker run \
  --name api-server-playground \
  -it \
  --rm \
  --network host \
  --volume /etc/kubernetes:/etc/kubernetes:ro \
  --volume /etc/pki:/etc/pki:ro \
  --volume /etc/ssl:/etc/ssl/:ro …

如何使用 REST API 创建 Pod？

我查看了 Kubernetes API 文档：https ://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#-strong-write-operations-strong--54

他们正在写需要使用 POST 请求：
POST /api/v1/namespaces/{namespace}/pods

我有这个简单的 nginx pod 的 YAML：

cat > nginx-pod.yaml <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx1
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80
EOF

我使用的是Kube版本v1.13.0.由于Heapster从v1.11开始折旧,因此我无法启用集群度量标准的API服务器来实现HPA.

附图供参考

有人可以指导我逐步启用API Metrics服务器或任何演示视频.继续前进真的很有帮助.

如果需要任何进一步的信息,请告诉我.

谢谢迪娜

当我尝试启动 kube-apiserver 时，我收到以下日志：

I1215 14:18:23.130968       1 controller.go:83] Starting OpenAPI controller
I1215 14:18:23.131021       1 customresource_discovery_controller.go:208] Starting DiscoveryController
I1215 14:18:23.131047       1 naming_controller.go:288] Starting NamingConditionController
I1215 14:18:23.131067       1 establishing_controller.go:73] Starting EstablishingController
I1215 14:18:23.131084       1 nonstructuralschema_controller.go:191] Starting NonStructuralSchemaConditionController
I1215 14:18:23.149275       1 controller_utils.go:1036] Caches are synced for crd-autoregister controller
I1215 14:18:23.191491       1 client.go:354] parsed scheme: ""
I1215 14:18:23.191600       1 client.go:354] scheme "" not registered, fallback to default scheme
I1215 14:18:23.191681       1 asm_amd64.s:1337] ccResolverWrapper: sending new addresses to cc: [{127.0.0.1:2379 0  <nil>}]
I1215 14:18:23.206235       1 asm_amd64.s:1337] …

我的 CRD 很少，但我不确定如何查询 kube-apiserver 以获取 CR 列表。任何人都可以提供任何示例代码吗？

我使用 Go 中的 client-go API 来访问给定控制器（部署）下的 Pod 列表。使用选择器标签查询属于它的 pod 列表时，您会得到一个数组PodConditions- https://pkg.go.dev/k8s.io/api/core/v1?tab=doc#PodCondition。

这与 Pod 条件的官方文档非常一致 - https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions。但文档并不清楚如何访问这个条目数组。是按照最近的条目先排序吗？例如，如果我只想访问 Pod 的最新状态，应该怎么做？从我在本地集群中进行的一项试验中，我获得了控制器 Pod 之一的更新（Pod 条件数组），如下所示

{Initialized True 0001-01-01 00:00:00 +0000 UTC 2020-07-29 08:01:15 +0000 UTC  } 
{Ready True 0001-01-01 00:00:00 +0000 UTC 2020-07-29 08:01:22 +0000 UTC  } 
{ContainersReady True 0001-01-01 00:00:00 +0000 UTC 2020-07-29 08:01:22 +0000 UTC  } 
{PodScheduled True 0001-01-01 00:00:00 +0000 UTC 2020-07-29 08:01:15 +0000 UTC  }

正如您所看到的，给定的 Pod几乎同时从 转变ContainersReady为。但它们都不在第一个或最后一个索引中。Ready08:01:22 +0000 UTC

TLDR，问题是如何从这个值数组推断最新的 Pod …

我的集群中有一个 wehook 正在运行。

我创建了一个证书并成功签名。

证书配置：

cat > csr.conf <<EOF
[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = s-controller.ns-controller
DNS.2 = s-controller.ns-controller.svc
EOF

我按如下方式创建证书：

openssl genrsa -out server-key.pem 2048
openssl req -new -key server-key.pem -subj "/CN=s-controller.ns-controller.svc" -out server.csr -config csr.conf

证书签名请求 ( v1beta1)

cat <<EOF | kubectl create -f -
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
    name: csr-controller
spec:
    groups:
    - …