不可否认，现在baidu、google中一搜一大把关于kubernetes方面的资料，在学习的过程中也大量阅览了其中不少，但是仍然发现很多问题
- 资料中的kubernetes版本略低，当前版本为0.18.1，文档中则多为0.6.x - 0.9.x，变化可想之大。
- kubernetes本身变化太快，文档略跟不上，即使在其官网，文档的速度也略跟不上版本发展的速度，kubernetes本身的命令、参数也略有不同。
基于这两点，我也只好依照参考为辅动手为主的原则来实验一把,实验的kubernetes版本为0.18.1
先简单贴上两张图来解释下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 -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
解压后，脚本路径为：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 的参数说明：
- 运行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的参数说明：
- 运行kube-scheduler：
./kube-scheduler --master='127.0.0.1:8080' \ --v=0 \ --log_dir=/var/log/kube
kube-scheduler的参数说明：
slave：
- 运行kube-proxy：
./kube-proxy --logtostderr=false \ --v=0 \ --master=http://172.30.12.255:8080
kube-proxy的参数说明：
- 运行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的参数说明：
创建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/pausedocker 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 MESSAGEfedoraapache 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 rcCONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICASlianjiatest.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 svcNAME LABELS SELECTOR IP(S) PORT(S)kubernetes component=apiserver,provider=kubernetes10.254.0.2 443/TCPkubernetes-ro component=apiserver,provider=kubernetes 10.254.0.1 80/TCPwebserver 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"｝保持一致；