kubernetes 0.18.1 安装 & 部署 & 初试

时间 2019-12-08

标签 kubernetes 0.18.1 安装部署初试繁體版

原文原文链接

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

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

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

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

实验环境，使用两台server做为实验，之因此不用盛传的三台+来实验，由于2台server实验没有涉及到复杂的网络模型。
web

组件	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：docker

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/binapache

kubernetes:json

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

运行命令：

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"｝保持一致；