kubernetes下heapster的部署案例

  • 时间:
  • 浏览:4

注意,这里4个 -subj "***"中第八个要写hostname,且强烈建议第4个subj和第八个这样多说相同(设为相同可能会意味着普通的curl https命令认证失败)。具体关于证书的生成,还还后能 参考: http://wangzhezhe.github.io/blog/2015/08/05/httpsandgolang/ 执行哪几次命令后,会生成一系列文件,将它们一同copy到master的/var/run/kubernetes/中,这样来越多这样来越多人的master启动要用哪几次证书文件:

本文转自SegmentFault-kubernetes下heapster的部署案例

刚刚启动k8smaster后,这样来越多这样来越多人就会发现

现在这样来越多这样来越多人还后能 4个hostname为vm-56-65的证书,执行哪几次命令:

这样来越多这样来越多人执行:

apiserver在启动的之总我让你本人创建4个key和crt(见/var/run/kubernetes/apiserver.crtapiserver.key

不止这样 ,假若再再加4个token的配置,就还还后能 在任何一台能与10.58.56.65直连的机器上,向apiserver做带认证的https请求。

这就麻烦了,用脚本启动k8s,启动的刚刚是会自动创建4个serviceaccount的,而serviceaccount创建出来的刚刚又会自动创建4个secret作为你这种serviceaccount的token。

注意,这里可能会启动apiserver失败,可能启动后这样 效果,可能这样 secrets的serviceaccount会保处在etcd中,这样来越多这样来越多这样来越多这样来越多人在正常启动前最好删掉etcd中的旧数据($etcdctl rm --recursive registry)。

如下是我heapster启动的json(4个replicationcontroller)

正常启动后这样来越多这样来越多人在你这种清况 下创建pod,pod中会加入serviceaccount你这种字段,即便这样来越多这样来越多人在创建的json或yaml中不指定,这样 它的默认值也会是默认的serviceaccount:default。 而你这种serviceaccount的secret就会被导入到pod启动的containers中。 举个例子,这样来越多这样来越多人在你这种清况 下创建4个pod,这样来越多这样来越多 执行:

我的环境: K8S1.0.0+flannel+docker1.6的分布式集群。

这里"env"中的环境变量是还后能 要加的,这样来越多这样来越多 heapster会报错,具体哪几次错不大记得了,应该是有关10.0.0.1 你这种域名的(heapster中的KUBERNETES_SERVICE_HOST变量默认是10.0.0.1)。 *10.0.0.1是k8s集群中master服务的ClusterIP(kubectl get svc 就还还后能 想看 ),这样来越多这样来越多slaver是还还后能 通过你这种ip:port访问到master服务的。这样来越多这样来越多 可能heapster做的是https的请求,还后能 crt证书和token。而10.0.0.1都在4个hostname这样来越多这样来越多 这样 相关的证书(感觉这是heapster最大的4个坑),这样来越多这样来越多我干脆我本人做证书,我本人做hosts引导,我本人做环境变量。

结果如下:

有了serviceaccountName字段,这样来越多这样来越多 volumn装载了4个secret.是的,你这种secret:default-token-n0i1i这样来越多这样来越多 这样来越多这样来越多人default你这种serviceaccount下的secret。它被装载到mountPath: /var/run/secrets/kubernetes.io/serviceaccount目录中,这样来越多这样来越多人可能在slaver上进入相关容器,便还还后能 找到你这种目录和相应的token(注:创建你这种pod的json中这样多指定serviceaccount,这样来越多这样来越多 用写volumn字段去挂载secret,哪几次总要自动完成的,否是还还后能 手动指定呢?期待大神们的指点)。

刚刚启动了apiserver后,这样来越多这样来越多人再重新create pod。 容器启动,这样来越多这样来越多人进入pod的日志,想看 非常多的:

如前文所说,我这里用了物理ip,当然,可能这样来越多这样来越多人这里配10.0.0.1 也是还还后能 的(可能使用10.0.0.1,api-server启动的刚刚就这样多再再加--secure-port=443了)。 具体为社 在么在进容器、改hosts这里我让你不细讲了,这样来越多这样来越多人都懂的~

我认为这是可能heapster在运行时还后能 向k8smaster做https的连接,这样来越多这样来越多 这样 token和证书是不到连接的,heapster的多多tcp连接 不出token就error并exit了,k8s会再启动之,于是就反复restart。

这里先不赘述flannel的部署了,刚刚有时间再写 相关的文档。

在yaml中会发现:

heapster最大的好处是其抓取的监控数据还还后能 按pod,container,namespace等最好的妙招group,刚刚就能进行监控信息的隐私化,即每个k8s的用户不到想看 我本人的应用的资源使用清况 ,而后台管理者又能想看 每台机器的资源使用清况 ,这种自动扩容这种的功能都在了4个可靠的信息来源。

这里--secure-port=443 是可能我在heapster访问master时,这样 采用结构ClusterIP,这样来越多这样来越多 直接访问物理IP,而端口这样 变,这样来越多这样来越多将master上apiserver的https监听端口修改了以便访问。

本案例在我的部署环境下是可行的,但不保证在所有环境下都可行。我尽可能讲得直白而全部,可能我我本人也才刚刚刚刚开始英语 接触,可能做很深入研究的还还后能 浏览,若有哪几次错误,烦请指正,感激不尽!

这样来越多这样来越多 在启动./kube-controller-manager 时再加flag:

这样来越多这样来越多人在apiserver的启动参数中再加:

这样 是正常的(用脚本启动的kubernetes一般会是刚刚的清况 ) 而可能是:

可能如下:

先讲讲kubernetes的serviceaccount,这样来越多这样来越多人的服务有刚刚还后能 这样来越多这样来越多饱含隐私信息的东西,token,certification file等等,哪几次东西这样来越多这样来越多人还还后能 在master上创建,这样来越多这样来越多 在创建pod的刚刚导入进去。具体还还后能 去看github上的secret.md,那里有具体的例子。

进入容器中修改容器里的/etc/hosts,再加4个:

修改完毕后,再刷新几次pod的日志,会发现,日志慢慢就不更新了(可能该说,不报错了),恭喜你,heapster可能在正常跑了。

为哪几次要先说哪几次呢? 可能这样来越多这样来越多人的heapster启动的之总要有你这种清况 : pod清况 为running,这样来越多这样来越多 反复地restart;这样来越多这样来越多人用webapi查看该pod的日志,发现: