开始配置Kubernetes集群的时候为了少出问题，都是在apiserver配置中去掉ServiceAccount采用非安全连接的方式，但在后面配置FEK日志的过程中，很多时候绕不开这个安全机制，但因为开始在centos上安装是通过yum的方式，所以那些ca.crt,server.crt,kubecfg.key等文件都是没有的。自己手工去建了好几次最后都有一些问题。

本文是基于git-hub中make-ca-cert方式自己建立，方法如下:

先把github中kubernetes代码都下栽到master本地。

# git clone https://github.com/kubernetes/kubernetes


修改make-ca-cert.sh,将第30行修改为kube(基于kube的组进行启动)

# update the below line with the group that exists on Kubernetes Master.
/* Use the user group with which you are planning to run kubernetes services */
cert_group=${CERT_GROUP:-kube}

运行make-ca-cert.sh

# cd kubernetes/cluster/saltbase/salt/generate-cert/

bash make-ca-cert.sh "192.168.0.105" "IP:192.168.0.105,IP:10.254.0.1,DNS:kubernetes,DNS:kubernetes.default,DNS:kubernetes.default.svc,DNS:kubernetes.default.svc.cluster.local"

 


这里192.168.0.105是master节点的ip,这种方式有个问题是master的ip变化的化证书可能有问题。不知道是否支持主机名设置。

 运行完后发现在/srv/kubernetes目录下已经把相关的key都生成了，把这些key考到所有的minion节点的相同目录。

 

然后配置/etc/kubernetes/apiserver

KUBE_API_ARGS="--secure-port=443 --client-ca-file=/srv/kubernetes/ca.crt --tls-cert-file=/srv/kubernetes/server.cert --tls-private-key-file=/srv/kubernetes/server.key"

 

配置/etc/kubernetes/controller-manager

KUBE_CONTROLLER_MANAGER_ARGS="--root-ca-file=/srv/kubernetes/ca.crt --service-account-private-key-file=/srv/kubernetes/server.key"

 

启动master和minion完成

On Master:
systemctl enable kube-apiserver
systemctl start kube-apiserver
systemctl enable kube-controller-manager
systemctl start kube-controller-manager
systemctl start kube-scheduler
systemctl start kube-scheduler
systemctl enable flanneld
systemctl start flanneld
 
Minions:
systemctl enable kube-proxy
systemctl start kube-proxy
systemctl enable kubelet
systemctl start kubelet
systemctl enable flanneld
systemctl start flanneld
systemctl enable docker
systemctl start docker
 
启动kube-apiserver的时候,如果是通过systemctl来启动的,可以在/etc/log/messages中看到启动日志

我对这个Failed to list *api.Secret的错误查了半天网上的材料想要消除,但后来看起来应该没有太大影响.

如果通过systemctl 启动不成功,可能尝试命令行启动.

APIServer和Controller Manager的命令行启动方式

/usr/bin/kube-apiserver --logtostderr=true --v=0 --etcd-servers=http://k8s-master:2379 --address=192.168.0.105 --port=8080 --kubelet-port=10250 --allow-privileged=true --service-cluster-ip-range=10.254.0.0/16 --admission-control=ServiceAccount --insecure-bind-address=192.168.0.105 --client-ca-file=/srv/kubernetes/ca.crt --tls-cert-file=/srv/kubernetes/server.cert --tls-private-key-file=/srv/kubernetes/server.key --secure-port=443 
 
/usr/bin/kube-controller-manager --logtostderr=true --v=0 --master=http://k8s-master:8080 --root-ca-file=/srv/kubernetes/ca.crt --service-account-private-key-file=/srv/kubernetes/server.key



Logo
Cloudpods

开源、云原生的融合云平台

更多推荐

面向未来的 IT 基础设施管理架构——融合云（Unified IaaS）

随着数字化时代的到来，IT系统已成为人类社会正常运转不可或缺的组成部分。不远的未来，智能制造，5G和人工智能等技术将成为推动生产力发展的重要引擎，人类社会将面临前所未有的全面彻底的数字化浪潮。IT基础设施作为IT系统运行的平台和载体，是实现数字化的基石。在这场数字化浪潮中，企业必须积极拥抱云计算技术，采用符合技术发展趋势、面向未来的IT基础构架，才能在未来的竞争中赢得先机。 一、云计算历经十余年

avatar Cloudpods

Cloudpods负载均衡的功能介绍

作者:周有松 今天的内容会从以下几个方面展开： 负载均衡产品简介。主要介绍负载均衡作为一个云上产品，它的功能模型是怎样的，日常使用中会遇到的业务词汇负载均衡的功能与典型应用场景。这部分主要结合业务词汇，对负载均衡服务中常见的一些功能选项进行介绍，并举例介绍一些典型的应用场景最后，我们做一下总结，讨论一下负载均衡产品相比传统方式的优点 一、产品简介​ 1. 以NGINX为例​ 提到负载均衡，我们以

avatar Cloudpods

使用Linux vfio将Nvidia GPU透传给QEMU虚拟机

Linux 上虚拟机 GPU 透传需要使用 vfio 的方式。主要是因为在 vfio 方式下对虚拟设备的权限和 DMA 隔离上做的更好。但是这么做也有个缺点，这个物理设备在主机和其他虚拟机都不能使用了。 qemu 直接使用物理设备本身命令行是很简单的，关键在于事先在主机上对系统、内核和物理设备的一些配置。 单纯从 qemu 的命令行来看，其实和普通虚拟机启动就差了最后那个-device的选项。这

avatar Cloudpods