不可否认，现在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 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"｝保持一致；
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。