kubernetes 0.18.1 安装 & 部署 & 初试

刘阳龙Herman

不可否认,现在baidu、google中一搜一大把关于kubernetes方面的资料,在学习的过程中也大量阅览了其中不少,但是仍然发现很多问题

  • 资料中的kubernetes版本略低,当前版本为0.18.1,文档中则多为0.6.x - 0.9.x,变化可想之大。
  • kubernetes本身变化太快,文档略跟不上,即使在其官网,文档的速度也略跟不上版本发展的速度,kubernetes本身的命令、参数也略有不同。

基于这两点,我也只好依照参考为辅动手为主的原则来实验一把,实验的kubernetes版本为0.18.1

先简单贴上两张图来解释下kubernetes的组件情况 & master/slave架构:
kubernetes组件架构

kubernetes  master/slave架构


实验环境,使用两台server作为实验,之所以不用盛传的三台+来实验,因为2台server实验没有涉及到复杂的网络模型。

组件 ip
etcd; kube-apiserver; kube-controller-manager; kube-scheduler 172.30.12.255/16
kube-proxy; kubelet 172.30.13.0/16

组件介绍:

  • kube-apiserver:作为kubernetes系统的入口,封装了核心对象的增删改查操作,以RESTFul接口方式提供给外部客户和内部组件调用。它维护的REST对象将持久化到etcd(一个分布式强一致性的key/value存储)。
  • kube-scheduler:负责集群的资源调度,为新建的pod分配机器。这部分工作分出来变成一个组件,意味着可以很方便地替换成其他的调度器。
  • kube-controller-manager:负责执行各种控制器,目前有两类:

    • endpoint-controller:定期关联service和pod(关联信息由endpoint对象维护),保证service到pod的映射总是最新的。
    • replication-controller:定期关联replicationController和pod,保证replicationController定义的复制数量与实际运行pod的数量总是一致的。
  • kube-proxy:负责为pod提供代理。它会定期从etcd获取所有的service,并根据service信息创建代理。当某个客户pod要访问其他pod时,访问请求会经过本机proxy做转发。
  • kubelet:负责管控docker容器,如启动/停止、监控运行状态等。它会定期从etcd获取分配到本机的pod,并根据pod信息启动或停止相应的容器。同时,它也会接收apiserver的HTTP请求,汇报pod的运行状态。

组件下载:

etcd:

curl -L https://github.com/coreos/etcd/releases/download/v2.0.11/etcd-v2.0.11-... -o etcd-v2.0.11-linux-amd64.tar.gz
tar zxvf etcd-v2.0.11-linux-amd64.tar.gz -C local/
ln -s etcd /usr/bin; ln -s etcdctl /usr/bin

kubernetes:

curl -L https://github.com/GoogleCloudPlatform/kubernetes/releases/download/v0...
解压后,脚本路径为:kubernetes/server/kubernetes/server/bin/
后续中,如果没有说明,默认执行路径为此。

运行命令:

master:

  • 运行etcd:
etcd > /var/log/etcd.log 2>&1 &
  • 运行kube-apiserver:
./kube-apiserver --address=0.0.0.0 \
                 --insecure-port=8080 \
                 --service-cluster-ip-range='10.254.0.0/16' \
                 --log_dir=/var/log/kube  \
                 --kubelet_port=10250 \
                 --v=0 \
                 --logtostderr=false \ 
                 --etcd_servers=http://127.0.0.1:4001 \
                 --allow_privileged=false

kube-apiserver 的参数说明:https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/man...

  • 运行kube-controller-manager:
./kube-controller-manager  --v=0 \
                           --logtostderr=false \
                           --log_dir=/var/log/kube  \
                           --machines=172.30.13.0  \
                           --master=127.0.0.1:8080

kube-controller-manager的参数说明:https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/man...

  • 运行kube-scheduler:
./kube-scheduler  --master='127.0.0.1:8080'  \
                  --v=0  \
                  --log_dir=/var/log/kube

kube-scheduler的参数说明:https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/man...

slave:

  • 运行kube-proxy:
./kube-proxy  --logtostderr=false  \
              --v=0  \
              --master=http://172.30.12.255:8080 

kube-proxy的参数说明:https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/man...

  • 运行kubelet:
./kubelet  --logtostderr=false  \
           --v=0  \
           --allow-privileged=false  \
           --log_dir=/var/log/kube  \
           --address=0.0.0.0  \
           --port=10250  \
           --hostname_override=172.30.13.0  \
           --api_servers=http://172.30.12.255:8080

kubelet的参数说明:https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/man...

创建pod:

pod:在Kubernetes系统中,调度的最小颗粒不是单纯的容器,而是抽象成一个Pod,Pod是一个可以被创建、销毁、调度、管理的最小的部署单元。比如一个或一组容器。

在master上创建json文件:test-pod.json

{
  "id": "fedoraapache",
  "kind": "Pod",
  "apiVersion": "v1beta1",
  "desiredState": {
    "manifest": {
      "version": "v1beta1",
      "id": "fedoraapache",
      "containers": [{
        "name": "fedoraapache",
        "image": "fedora/apache",
        "ports": [{
          "containerPort": 80,
          "hostPort": 8080
        }]
      }]
    }
  },
  "labels": {
    "name": "fedoraapache"
  }
}

运行命令:

./kubectl create -f test-pod.json

理论上,这样就ok了。
但是!!!!因为有伟大的GFW!!我们会在slave上看到一连串错误输出,大体为:

HTTP Error: statusCode=404 No such image: gcr.io/google_containers/pause:0.8.0

好吧,解决方案也山寨下。。。。。在slave上运行命令:

docker pull docker.io/kubernetes/pause
docker tag docker.io/kubernetes/pause gcr.io/google_containers/pause:0.8.0

这样,运行命令./kubectl create -f test-pod.json就可ok,至少看上去这样。
查看已经创建好的pod:

./kubectl get pods 

输出大概为:

POD            IP           CONTAINER(S)   IMAGE(S)        HOST                      LABELS              STATUS    CREATED   MESSAGE
fedoraapache   172.17.0.3                                  172.30.13.0/172.30.13.0   name=fedoraapache   Running   2 hours   
                            fedoraapache   fedora/apache                                                 Running   2 hours   

创建ReplicationController:

Replication Controller是Kubernetes系统中最有用的功能,实现复制多个Pod副本,往往一个应用需要多个Pod来支撑,并且可以保证其复制的副本数,即使副本所调度分配的主宿机出现异常,通过Replication Controller可以保证在其它主宿机启用同等数量的Pod。Replication Controller可以通过repcon模板来创建多个Pod副本,同样也可以直接复制已存在Pod,需要通过Label selector来关联。

在master上创建json文件:

{
    "id": "lianjiatest.com",
    "apiVersion": "v1beta1",
    "kind": "ReplicationController",
    "desiredState": {
      "replicas": 5,
      "replicaSelector": {"name": "liutest"},
      "podTemplate": {
        "desiredState": {
           "manifest": {
             "version": "v1beta1",
             "id": "apacheserver",
             "containers": [{
               "name": "apachetest",
               "image": "fedora/apache",
               "imagePullPolicy": "PullIfNotPresent",
               "ports": [{
                   "containerPort": 80
               }]
             }]
           }
         },
         "labels": {"name": "liutest"}
        }},
    "labels": {"name": "replicationtest"}
  }

在这里创建了5个副本的pod。
运行命令:

./kubectl create -f replicationcontroller.json 

这样就ok了,然后在master上查看:

./kubectl get rc

CONTROLLER        CONTAINER(S)   IMAGE(S)        SELECTOR       REPLICAS
lianjiatest.com   apachetest     fedora/apache   name=liutest   5

在slave上运行docker ps 可以看到:
图片描述
OK! 即使在slave删掉其中的几个,也会迅速补充到5个~~~~

创建service:

Services是Kubernetes最外围的单元,通过虚拟一个访问IP及服务端口,可以访问我们定义好的Pod资源,目前的版本是通过iptables的nat转发来实现,转发的目标端口为Kube_proxy生成的随机端口

在master上创建test-svc.json:

{
  "id": "webserver",
  "kind": "Service",
  "apiVersion": "v1beta1",
  "selector": {
    "name": "liutest"
  },
  "protocol": "TCP",
  "containerPort": 80,
  "port": 8080
}

运行命令:

./kubectl create -f test-svc.json

然后查看建立好的service:

./kubectl get svc
NAME            LABELS                                    SELECTOR       IP(S)            PORT(S)
kubernetes      component=apiserver,provider=kubernetes   <none>         10.254.0.2       443/TCP
kubernetes-ro   component=apiserver,provider=kubernetes   <none>         10.254.0.1       80/TCP
webserver       <none>                                    name=liutest   10.254.122.245   8080/TCP

现在到slave上看看映射的端口多少,在slave上运行iptables-save:

-A KUBE-PORTALS-HOST -d 10.254.122.245/32 -p tcp -m comment --comment "default/webserver:" -m tcp --dport 8080 -j DNAT --to-destination 172.30.13.161:40391 

ok,我们在浏览器中访问 172.30.13.161:40391,成功,请求是平均负载到创建的5个container中,可惜在本次测试中体现不出来~~

最后总结下注意点:
在replicationcontronllers.json中,"replicaSelector": {"name": "XXXXXX"}要与"labels": {"name": "XXXXXXX"}以及service中的"selector": {"name": "XXXXXXX"}保持一致;

阅读 26.8k

Herman.Liu
持续关注devops

Herman.Liu.1988.avi

669 声望
106 粉丝
0 条评论

Herman.Liu.1988.avi

669 声望
106 粉丝
文章目录
宣传栏