我知道每个 Kubernetes 节点上的 Kubelet 进程都公开了一个简单的 API 服务器，但我找不到任何文档。

有人知道拥有它的资源吗？

我正在尝试按照 CoreOS beta (1153.4.0) 上的https://coreos.com/kubernetes/docs/latest/deploy-master.html中的描述部署主节点。

我正在使用以下 kubeconfig yaml 文件：

我正在使用KUBELET_VERSIONv1.4.0-beta.10_coreos.0

systemctl cat kubelet返回以下内容：

/etc/systemd/system/kubelet.service

journalctl -b -u kubelet返回

我尝试指定 rkt 的特定路径，我尝试使用与我的核心操作系统上相同的路径，/bin/rkt但它在那里找不到二进制文件。超立方体图像是否由于某种原因缺少 rkt 二进制文件？

更新

好的，我尝试进一步调试此问题，但又陷入了死胡同。

我试图手动运行所有内容以查看问题出在哪里..

所以我设置了以下环境变量：

然后我将文件复制/usr/lib/coreos/kubelet-wrapper到我的主目录并修改它以运行 bash：

然后我使用以下参数运行 kubelet：

然后在得到 bash 提示后，我kubelet使用以下参数运行：

我再次收到cannot find rkt binary错误消息。我尝试rkt通过运行在该容器中找到二进制文件，find / | grep rkt$但没有找到 rkt 二进制文件。

我有两台装有 CoreOS beta (1185.2.0) 的 coreos 机器。

我使用修改后的脚本安装带有 rkt 容器的 kuberentes，原始脚本位于https://github.com/coreos/coreos-kubernetes/tree/master/multi-node/generic。修改后的版本位于https://github.com/kfirufk/coreos-kubernetes-multi-node-generic-install-script。

我为脚本设置的环境变量是：

最值得注意的变化是增加了对 etcd2 tls 证书和 kubeconfig yaml 使用的支持，而不是 depreated --api-server。

目前我正在尝试使用 coreos-2.tux-in.com 的控制器脚本进行安装。

控制器节点的 kubeconfig yaml 包含：

生成的kubelet.service文件包含

现在..我很确定它与使用有关，--kubeconfig而不是--api-server因为我在此更改后才开始收到此错误。

kubelet 日志输出位于http://pastebin.com/eD8TrMJJ

kubelet 现在没有正确安装，当我运行kubectl get nodes它时在我的桌面上返回一个空列表。

有任何想法吗？

更新

http://pastebin.com/gDBbn0rnkubectl get nodes --v=8的输出

更新

etcdctl ls /registry/minions输出：

ps -aef | grep kubelet在控制器上

ps -aef | grep kubelet对工人

更新

当我跑步时，journalctl -f -u kubelet我注意到每 10 秒我收到以下消息：

此消息与哪个服务相关？也许由于某种故障，某些东西每 10 秒就会重新启动一次。

出于某种原因，我们的谷歌容器有时会重新启动，而我们无法找到原因，这很好，我想如果它们再次快速启动，很遗憾并非如此。

问题似乎是持久磁盘卷的卸载速度不够快，当重新启动的容器尝试安装它时，它只是卡住了，你必须杀死它并手动启动它。

是否可以将容器配置为在重新挂载持久磁盘之前等待卸载，解决此问题的正确解决方案是什么？

我正在尝试在 CoreOS beta (1192.2.0) 上使用 kubelet 1.4.5 安装 kubernetes。

我正在使用来自https://github.com/coreos/coreos-kubernetes/tree/master/multi-node/generic的控制器和工作程序安装脚本的略微修改版本

所以总的来说，我使用以下 bash 脚本在 Gentoo Linux 上创建了许可证：

这是openssl.cnf

这是我的worker-openssl.cnf

我的控制器机器coreos-2.tux-in.com解析为 lan ip10.79.218.2

我的工作机器coreos-3.tux-in.com解析为 lan ip10.79.218.3

它创建了许可证就好了。但是当我使用它们并在主机上安装控制器脚本时，我看到当我运行时journalctl -xef -u kubelet，我注意到以下消息：

我的 kubelet 抱怨：

E1201 09:00:12.562610 28747 kubelet_network.go:365] 无法确保规则在过滤器链 KUBE-FIREWALL 中丢弃由 KUBE-MARK-DROP 标记的数据包：错误附加规则：退出状态 1：iptables：无链/目标/匹配用那个名字。

这通常发生在您忘记使用 --net-host 'rkt run' 时，但我没有。

export RKT_OPTS="--volume var-log,kind=host,source=/var/log \
--mount volume=var-log,target=/var/log \ --volume dns,kind=host,source=/ etc/resolv.conf \ --mount volume=dns,target=/etc/resolv.conf --net=host"

以下确认我的 kube-proxy（由 kubelet 启动）与拥有 iptables 链的主机位于同一命名空间中：

代理同样抱怨“没有该名称的链/目标/匹配”。

我还验证了 iptables 链：

这满足了错误消息中的抱怨（我认为）并匹配了无问题的 coreos 工作人员（我比较的不同机器）上的过滤器链。

问题工作者是运行 docker 1.12.3 和 rkt 1.18.0 的 Debian Jessie

好工人和问题工人都在运行相同版本的 iptables，1.4.21

KUBELET_VERSION=v1.4.6_coreos.0

症状是问题 worker 上的 kubernetes 没有安装任何 iptables 规则，例如 KUBE-NODEPORTS，因此该 worker 无法监听 NodePort 服务。我想是因为以上原因。

问题工作者运行主节点调度的 pod 没有问题。

问题工作人员上的 Pod 正在处理来自运行在不同（coreos）工作人员上的代理的请求。

我正在使用法兰绒进行联网。

如果有人想知道，我需要让 kubernetes 在 Debian 上工作（是的，说来话长）

我还能做些什么来隔离似乎 kubelet 没有看到主机的 iptables 的东西？

嗨，我正在关注此文档https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md#strategic-merge-patch以使用 strategy-merge-patch 部分更新 JSON 对象补丁 REST API。该文档说它可以添加或删除对象，但我已经尝试过，每当我向现有 JSON 添加新对象时，它只是替换它而不是添加新对象。我正在尝试修改 OpenShift 3.2 中的 pod 定义。谁能帮助我它是如何工作的，可能是例子。我还需要使用删除操作，我可以按名称删除值。

我家里有两台 CoreOS stable (1185.5.0) 服务器。我尝试在这两个上安装 kubernetes 控制器和工作者。

我使用 coreos-kubernetes 脚本从https://github.com/coreos/coreos-kubernetes/tree/master/multi-node/generic安装，并从https://github.com/kfirufk/coreos-kubernetes修补-多节点通用安装脚本。我rkt用来运行相关的容器。

我使用以下环境变量选项覆盖文件：

coreos-2.tux-in.com解析为10.79.218.2控制器节点。

coreos-3.tux-in.com解析为10.79.218.3工作节点。

控制器脚本似乎安装得很好。

当我尝试在第二台服务器上安装 kubernetes worker 时，我注意到 kubelet 日志中不断出现以下错误消息：

Invalid ETCD_CA_CERT_FILE错误信息显示提供的值为空，这表明由于某种原因未设置 ETCD_CA_CERT_FILE 环境变量。我尝试在[服务]下编辑/etc/systemd/system/kubelet.service和添加Environment=ETCD_CA_CERT_FILE=/etc/ssl/etcd/ca.pem，但结果是一样的。有任何想法吗 ？

我开始 kubelet

并在 kubelet 日志中获取：

无法向 API 服务器注册节点“pn-kube-minion_1-du27gtypmboj”：节点“pn-kube-minion_1-du27gtypmboj”无效：metadata.name：无效值：“pn-kube-minion_1-du27gtypmboj”：必须匹配正则表达式 a-z0-9?(.a-z0-9?)* (例如 'example.com')

看起来主机名覆盖被忽略，而是从虚拟机中提取主机名信息（我相信这是为了满足煤渣卷安装）

这是一个已知的问题？任何变通办法？

我正在尝试使用 ansible repo在我的 k8s 集群上设置 EFK 堆栈。

当我尝试浏览 kibana 仪表板时，它会显示下一个输出：

经过一番研究，我发现 Fluentd 没有检测到任何日志。我在 minions 上运行 k8s 1.2.4，在 master 上运行 1.2.0。我成功理解的是，kubelet 创建 /var/log/containers 目录，并将集群中运行的所有容器的符号链接放入其中。之后，Fluentd 从 minion 挂载共享 /var/log 卷，并最终可以访问所有日志容器。因此，它可以将这些日志发送到弹性搜索。

在我的情况下，我创建了 /var/log/containers，但它是空的，甚至 /var/lib/docker/containers 也不包含任何日志文件。我曾经使用以下控制器和服务进行 EFK 堆栈设置：

es-controller.yaml

apiVersion: v1 kind: ReplicationController metadata: name: elasticsearch-logging-v1 namespace: kube-system labels: k8s-app: elasticsearch-logging version: v1 kubernetes.io/cluster-service: "true" spec: replicas: 2 selector: k8s-app: elasticsearch-logging version: v1 template: metadata: labels: k8s-app: elasticsearch-logging version: v1 kubernetes.io/cluster-service: "true" spec: containers: - image: gcr.io/google_containers/elasticsearch:v2.4.1 name: elasticsearch-logging resources: # need more cpu upon initialization, therefore burstable class limits: cpu: 1000m requests: cpu: 100m ports: - containerPort: 9200 name: db protocol: TCP - containerPort: 9300 name: transport protocol: TCP volumeMounts: - name: es-persistent-storage mountPath: /data env: - name: "NAMESPACE" valueFrom: fieldRef: fieldPath: metadata.namespace volumes: - name: es-persistent-storage emptyDir: {}

es-service.yaml

apiVersion: v1 kind: Service metadata: name: elasticsearch-logging namespace: kube-system labels: k8s-app: elasticsearch-logging kubernetes.io/cluster-service: "true" kubernetes.io/name: "Elasticsearch" spec: ports: - port: 9200 protocol: TCP targetPort: db selector: k8s-app: elasticsearch-logging

fluentd-es.yaml

apiVersion: v1 kind: Pod metadata: name: fluentd-es-v1.20 namespace: kube-system labels: k8s-app: fluentd-es version: v1.20 spec: containers: - name: fluentd-es image: gcr.io/google_containers/fluentd-elasticsearch:1.20 command: - '/bin/sh' - '-c' - '/usr/sbin/td-agent 2>&1 >> /var/log/fluentd.log' resources: limits: cpu: 100m volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true terminationGracePeriodSeconds: 30 volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers

kibana-controller.yaml

apiVersion: extensions/v1beta1 kind: Deployment metadata: name: kibana-logging namespace: kube-system labels: k8s-app: kibana-logging kubernetes.io/cluster-service: "true" spec: replicas: 1 selector: matchLabels: k8s-app: kibana-logging template: metadata: labels: k8s-app: kibana-logging spec: containers: - name: kibana-logging image: gcr.io/google_containers/kibana:v4.6.1 resources: # keep request = limit to keep this container in guaranteed class limits: cpu: 100m requests: cpu: 100m env: - name: "ELASTICSEARCH_URL" value: "http://elasticsearch-logging:9200" ports: - containerPort: 5601 name: ui protocol: TCP

kibana-service.yaml

apiVersion: v1 kind: Service metadata: name: kibana-logging namespace: kube-system labels: k8s-app: kibana-logging kubernetes.io/cluster-service: "true" kubernetes.io/name: "Kibana" spec: type: NodePort ports: - port: 5601 protocol: TCP targetPort: ui selector: k8s-app: kibana-logging

更新：

我将 fluentd-es.yaml 更改如下：

apiVersion: v1 kind: Pod metadata: name: fluentd-elasticsearch namespace: kube-system labels: k8s-app: fluentd-logging spec: containers: - name: fluentd-elasticsearch image: gcr.io/google_containers/fluentd-elasticsearch:1.15 resources: limits: memory: 200Mi requests: cpu: 100m memory: 200Mi volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true terminationGracePeriodSeconds: 30 volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers

但是当我运行一个“命名网关”的 pod 时，我在 fluentd 日志中得到了下一个错误： /var/log/containers/gateway-c3cuu_default_gateway-d5966a86e7cb1519329272a0b900182be81f55524227db2f524e6e23cd75ba04.log unreadable. It is excluded and would be examined next time.