資訊專欄INFORMATION COLUMN
摘要：部署環(huán)境及架構(gòu)操作系統(tǒng)版本版本版本服務(wù)器信息在詳細(xì)介紹部署集群前，先給大家展示下集群的邏輯架構(gòu)。其他操作更新刪除查看刪除除此之外，你可以刪除，如刪除上的格式為服務(wù)名字，不必關(guān)心從哪個(gè)上刪除了。
本文通過(guò)實(shí)際操作來(lái)演示Kubernetes的使用，因?yàn)榄h(huán)境有限，集群部署在本地3個(gè)ubuntu上，主要包括如下內(nèi)容：
部署環(huán)境介紹，以及Kubernetes集群邏輯架構(gòu)
安裝部署Open vSwitch跨機(jī)器容器通信工具
安裝部署Etcd和Kubernetes的各大組件
演示Kubernetes管理容器和服務(wù)
關(guān)于 Kubernetes 系統(tǒng)架構(gòu)及組件介紹見(jiàn)這里。
1. 部署環(huán)境及架構(gòu)vSphere: 5.1
操作系統(tǒng): ubuntu 14.04 x86_64
Open vSwith版本: 2.0.2
Kubernetes: v0.7.2
Etcd版本: 2.0.0-rc.1
Docker版本: 1.4.1
服務(wù)器信息：
| Role | Hostname | IP Address |
|---|---|---|
| APIServer | kubernetes | 172.29.88.206 |
| Minion | minion1 | 172.29.88.207 |
| Minion | minion2 | 172.29.88.208 |
在詳細(xì)介紹部署Kubernetes集群前，先給大家展示下集群的邏輯架構(gòu)。從下圖可知，整個(gè)系統(tǒng)分為兩部分，第一部分是Kubernetes APIServer，是整個(gè)系統(tǒng)的核心，承擔(dān)集群中所有容器的管理工作；第二部分是minion，運(yùn)行Container Daemon，是所有容器棲息之地，同時(shí)在minion上運(yùn)行Open vSwitch程序，通過(guò)GRE Tunnel負(fù)責(zé)minions之間Pod的網(wǎng)絡(luò)通信工作。
為了解決跨minion之間Pod的通信問(wèn)題，我們?cè)诿總€(gè)minion上安裝Open vSwtich，并使用GRE或者VxLAN使得跨機(jī)器之間P11od能相互通信，本文使用GRE，而VxLAN通常用在需要隔離的大規(guī)模網(wǎng)絡(luò)中。對(duì)于Open vSwitch的介紹請(qǐng)參考另一篇文章Open vSwitch。
sudo apt-get install openvswitch-switch bridge-utils
安裝完Open vSwitch和橋接工具后，接下來(lái)便建立minion0和minion1之間的隧道。首先在minion1和minion2上分別建立OVS Bridge：
# ovs-vsctl add-br obr0
接下來(lái)建立gre，并將新建的gre0添加到obr0，在minion1上執(zhí)行如下命令：
# ovs-vsctl add-port obr0 gre0 -- set Interface gre0 type=gre options:remote_ip=172.29.88.208
上面的remoute_ip是另一臺(tái)服務(wù)minion2上的對(duì)外IP。
在minion2上執(zhí)行：
# ovs-vsctl add-port obr0 gre0 -- set Interface gre0 type=gre options:remote_ip=172.29.88.207
至此，minion1和minion2之間的隧道已經(jīng)建立。然后我們?cè)趍inion1和minion2上創(chuàng)建Linux網(wǎng)橋kbr0替代Docker默認(rèn)的docker0（我們假設(shè)minion1和minion2都已安裝Docker），設(shè)置minion1的kbr0的地址為172.17.1.1/24， minion2的kbr0的地址為172.17.2.1/24，并添加obr0為kbr0的接口，以下命令在minion1和minion2上執(zhí)行：
# brctl addbr kbr0 //創(chuàng)建linux bridge代替docker0 # brctl addif kbr0 obr0 //添加obr0為kbr0的接口 # ip link set dev docker0 down //設(shè)置docker0為down狀態(tài) # ip link del dev docker0 //刪除docker0，可選
查看這些接口的狀態(tài)：
# service openvswitch-switch status
# ovs-vsctl show
9d248403-943c-41c0-b2d0-3f9b130cdd3f
Bridge "obr0"
Port "gre0"
Interface "gre0"
type: gre
options: {remote_ip="172.29.88.207"}
Port "obr0"
Interface "obr0"
type: internal
ovs_version: "2.0.2"
# brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.56847afe9799 no
kbr0 8000.620ff7ee9c49 no obr0
為了使新建的kbr0在每次系統(tǒng)重啟后任然有效，我們?cè)趍inion1的/etc/network/interfaces文件中追加內(nèi)容如下：（在CentOS上會(huì)有些不一樣）
# vi /etc/network/interfaces
auto kbr0
iface kbr0 inet static
address 172.17.1.1
netmask 255.255.255.0
gateway 172.17.1.0
dns-nameservers 172.31.1.1
同樣在minion2上追加類(lèi)似內(nèi)容，只需修改address為172.17.2.1和gateway為172.17.2.0即可，然后執(zhí)行ip link set dev kbr0 up，你能在minion1和minion2上發(fā)現(xiàn)kbr0都設(shè)置了相應(yīng)的IP地址。為了驗(yàn)證我們創(chuàng)建的隧道是否能通信，我們?cè)趍inion1和minion2上相互ping對(duì)方kbr0的IP地址，從下面的結(jié)果發(fā)現(xiàn)是不通的，經(jīng)查找這是因?yàn)樵趍inion1和minion2上缺少訪問(wèn)172.17.1.1和172.17.2.1的路由，因此我們需要添加路由保證彼此之間能通信：
minion1上執(zhí)行: # ip route add 172.17.2.0/24 via 172.29.88.208 dev eth0 minion2上執(zhí)行: # ip route add 172.17.1.0/24 via 172.29.88.207 dev eth0
現(xiàn)在可以ping通對(duì)方的虛擬網(wǎng)絡(luò)了：
$ ping 172.17.2.1 PING 172.17.2.1 (172.17.2.1) 56(84) bytes of data. 64 bytes from 172.17.2.1: icmp_seq=1 ttl=64 time=0.334 ms 64 bytes from 172.17.2.1: icmp_seq=2 ttl=64 time=0.253 ms ^C --- 172.17.2.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.253/0.293/0.334/0.043 ms
下面安裝 Kubernetes APIServer 及kubelet、proxy等服務(wù)。
3. 安裝Kubernetes APIServer 3.1 下載安裝kubernetes各組件可以自己從源碼編譯kubernetes（需要安裝golang環(huán)境），也可以從GitHub Kubernetes repo release page.選擇編譯好的二進(jìn)制版本（v0.7.2）下載，為了方便后面啟動(dòng)或關(guān)閉kubernetes組件，我們同時(shí)下載二進(jìn)制包和源碼包：
# cd /usr/local/src # wget https://github.com/coreos/etcd/releases/download/v2.0.0-rc.1/etcd-v2.0.0-rc.1-linux-amd64.tar.gz # wget https://github.com/GoogleCloudPlatform/kubernetes/releases/download/v0.7.2/kubernetes.tar.gz # wget https://github.com/GoogleCloudPlatform/kubernetes/archive/v0.7.2.zip
然后解壓下載的kubernetes和etcd包，并在kubernetes(minion1)、minion2上創(chuàng)建目錄/opt/bin
# mkdir /opt/bin //這一步APIserver和所有minions上都要?jiǎng)?chuàng)建 解壓kubernetes src# tar xf kubernetes.tar.gz # ll drwxr-xr-x 3 501 staff 4096 Dec 19 02:32 etcd-v2.0.0-rc.1-linux-amd64/ -rw-r--r-- 1 root root 6223584 Jan 6 14:39 etcd-v2.0.0-rc.1-linux-amd64.tar.gz drwxr-xr-x 7 root root 4096 Nov 20 06:35 kubernetes/ -rw-r--r-- 1 root root 82300483 Jan 6 14:37 kubernetes.tar.gz -rw-r--r-- 1 root root 9170754 Jan 9 14:47 v0.7.2.zip # cd kubernetes/server # tar xf kubernetes-server-linux-amd64.tar.gz # cd kubernetes/server/bin/ APIserver本身需要的是kube-apiserver kube-scheduler kube-controller-manager kubecfg四個(gè) # cp -a kube* /opt/bin/ 把proxy和kubelet復(fù)制到其他minions，確保這些文件都是可執(zhí)行的 # scp kube-proxy kubelet root@172.29.88.207:/opt/bin # scp kube-proxy kubelet root@172.29.88.208:/opt/bin
/opt/bin并沒(méi)有加入系統(tǒng)PATH，所以kube-apiserver -version是看不到結(jié)果，但在后面配置的服務(wù)中會(huì)自動(dòng)加入（PATH=$PATH:/opt/bin）。
3.2 解壓安裝etcdetcd在這里的作用是服務(wù)發(fā)現(xiàn)存儲(chǔ)倉(cāng)庫(kù)，通俗的來(lái)講就是記錄kubernetes啟動(dòng)了多少pods、services、replicationController以及它們的信息等，詳細(xì)介紹見(jiàn)這里。此外版本2.0與v0.4.6在啟動(dòng)參數(shù)上的寫(xiě)法有一定差別。
# tar xf etcd-v2.0.0-rc.1-linux-amd64.tar.gz && cd etcd-v2.0.0-rc.1-linux-amd64/ # cp -a etcd etcdctl /opt/bin3.3 配置kube-apiserver等為upstart腳本啟動(dòng)
這一步主要是為了管理kube-apiserver等進(jìn)程的方便，避免每次都手動(dòng)啟動(dòng)各服務(wù)、添加冗長(zhǎng)的啟動(dòng)參數(shù)選項(xiàng)，而且在不同的系統(tǒng)平臺(tái)下kubernetes已經(jīng)提供了相應(yīng)的工具。
解壓kubernetes*源碼包* src# unzip xf v0.7.2.zip && cd kubernetes-0.7.2 這里比較奇怪的是最新release版本源碼的cluster目錄下是有ubuntu子目錄的，但latest之前的下載后沒(méi)有ubuntu目錄 # cd cluster/ubuntu # ll .. 2 root root 4096 Jan 8 17:39 default_scripts/ 各組件默認(rèn)啟動(dòng)參數(shù) .. 2 root root 4096 Jan 8 17:39 init_conf/ upstart啟動(dòng)方式 .. 2 root root 4096 Jan 8 17:39 initd_scripts/ service啟動(dòng)方式，與upstart選其一 .. 1 root root 1213 Jan 8 08:53 util.sh* # ./util.sh
util.sh腳本就是把當(dāng)前目錄下的service/upstart腳本、默認(rèn)參數(shù)配置文件復(fù)制到/etc下，可以通過(guò)service etcd start的形式管理kubernetes。由于kubernetes更新速度極快，項(xiàng)目的文件和目錄結(jié)構(gòu)經(jīng)常變化，請(qǐng)找準(zhǔn)文件。接下來(lái)我們需要修改那些只適合本機(jī)使用的默認(rèn)參數(shù)。（請(qǐng)注意備份先，因?yàn)楹竺婺芊裾？鐧C(jī)器管理docker與這些選項(xiàng)有關(guān)，特別是IP）
etcd官方建議使用新的2379端口代替4001
# vi /etc/default/etcd
ETCD_OPTS="-listen-client-urls=http://0.0.0.0:4001"
# vi /etc/default/kube-apiserver
KUBE_APISERVER_OPTS="--address=0.0.0.0
--port=8080
--etcd_servers=http://127.0.0.1:4001
--logtostderr=true
--portal_net=11.1.1.0/24"
# vi /etc/default/kube-scheduler
KUBE_SCHEDULER_OPTS="--logtostderr=true
--master=127.0.0.1:8080"
# vi /etc/default/kube-controller-manager
KUBE_CONTROLLER_MANAGER_OPTS="--master=127.0.0.1:8080
--machines=172.29.88.207,172.29.88.208
--logtostderr=true"
* 復(fù)制kubelet、kube-proxy等到minion1：
# scp /etc/default/{kubelet,kube-proxy} 172.29.88.207:/etc/default/
# scp /etc/init.d/{kubelet,kube-proxy} 172.29.88.207:/etc/init.d/
# scp /etc/init/{kubelet.conf,kube-proxy.conf} 172.29.88.207:/etc/init/
* 在minion1端進(jìn)行 # vi /etc/default/kubelet KUBELET_OPTS="--address=172.29.88.207 --port=10250 --hostname_override=172.29.88.207 --etcd_servers=http://172.29.88.206:4001 --logtostderr=true" # vi /etc/default/kube-proxy KUBE_PROXY_OPTS="--etcd_servers=http://172.29.88.207:4001 --logtostderr=true" (對(duì)minion2重復(fù)上面 * 兩個(gè)步驟，把上面.207改成.208)
上面的各配置文件就是對(duì)應(yīng)命令的選項(xiàng)，具體含義使用-h。這里只簡(jiǎn)單說(shuō)明：
etcd服務(wù)APIserver和minions都要訪問(wèn)，也就是其他組件的--etcd_servers值（帶http前綴）
kube-apiserver監(jiān)聽(tīng)在8080端口，也就是其他組件的--master值；--portal_net地址段不能與docker的橋接網(wǎng)卡kbr0重復(fù)，指定docker容器的IP段
etcd、kube-apiserver、kube-scheduler、kube-controller-manager運(yùn)行在apiserver（服務(wù)）端，kubelet、kube-proxy運(yùn)行在minion（客戶端）
kube-controller-manager使用預(yù)先定義pod模板創(chuàng)建pods，保證指定數(shù)量的replicas在運(yùn)行，默認(rèn)監(jiān)聽(tīng)在master的127.0.0.1:10252
kubelet默認(rèn)監(jiān)聽(tīng)端口10250，也正是apiserver的--kubelet_port的值
3.4 啟動(dòng)重啟docker
接下來(lái)重啟minion1、minion2上的Docker daemon（注意使用的網(wǎng)橋）：
# docker -d -b kbr0
由于后面的測(cè)試可能需要在線下載images，所以如果你的服務(wù)器無(wú)法訪問(wèn)docker hub，上面啟動(dòng)時(shí)記得設(shè)置HTTP_PROXY代理。
啟動(dòng)apiserver
# service etcd start # service kube-apiserver start
kube-apiserver啟動(dòng)后會(huì)自動(dòng)運(yùn)行kube-scheduler、kube-controller-manager，但修改配置后依然可以多帶帶重啟各個(gè)服務(wù)如service kube-contoller-manager restart。這些服務(wù)的日志可以從/var/log/upstart/kube*找到。
在minion1、minion2上啟動(dòng)kubelet、kube-proxy：
# service kubelet start # service kube-proxy start4. 使用kubecfg部署測(cè)試應(yīng)用
為了方便，我們使用Kubernetes提供的例子Guestbook（下載的源碼example目錄下可以找到）來(lái)演示Kubernetes管理跨機(jī)器運(yùn)行的容器，下面我們根據(jù)Guestbook的步驟創(chuàng)建容器及服務(wù)。在下面的過(guò)程中如果是第一次操作，可能會(huì)有一定的等待時(shí)間，狀態(tài)處于pending，這是因?yàn)榈谝淮蜗螺dimages需要一段時(shí)間。
4.1 創(chuàng)建redis-master Pod和redis-master服務(wù)配置管理操作都在apiserver上執(zhí)行，并且都是基于實(shí)現(xiàn)編寫(xiě)好的json格式。涉及到下載docker鏡像的部分，如果沒(méi)有外網(wǎng)，可能需要修改image的值或使用自己搭建的docker-registry：
# cd kubernetes-0.7.2/examples/guestbook/
# cat redis-master.json
{
"id": "redis-master",
"kind": "Pod",
"apiVersion": "v1beta1",
"desiredState": {
"manifest": {
"version": "v1beta1",
"id": "redis-master",
"containers": [{
"name": "master",
"image": "dockerfile/redis",
"cpu": 100,
"ports": [{
"containerPort": 6379,
"hostPort": 6379
}]
}]
}
},
"labels": {
"name": "redis-master"
}
}
# kubecfg -h http://172.29.88.206:8080 -c redis-master.json create pods
# kubecfg -h http://172.29.88.206:8080 -c redis-master-service.json create services
完成上面的操作后，我們可以看到如下redis-master Pod被調(diào)度到172.29.88.207：
（下面直接list實(shí)際上是省略了-h http://127.0.0.1:8080）
# kubecfg list pods Name Image(s) Host Labels Status ---------- ---------- ---------- ---------- ---------- redis-master dockerfile/redis 172.29.88.207/ name=redis-master Running 查看services： # kubecfg list services Name Labels Selector IP Port ---------- ---------- ---------- ---------- ------ kubernetes component=apiserver,provider=kubernetes 11.1.1.233 443 kubernetes-ro component=apiserver,provider=kubernetes 11.1.1.204 80 redis-master name=redis-master name=redis-master 11.1.1.175 6379
發(fā)現(xiàn)除了redis-master的服務(wù)之外，還有兩個(gè)Kubernetes系統(tǒng)默認(rèn)的服務(wù)kubernetes-ro和kubernetes。而且我們可以看到每個(gè)服務(wù)都有一個(gè)服務(wù)IP及相應(yīng)的端口，對(duì)于服務(wù)IP，是一個(gè)虛擬地址，根據(jù)apiserver的portal_net選項(xiàng)設(shè)置的CIDR表示的IP地址段來(lái)選取，在我們的集群中設(shè)置為11.1.1.0/24。為此每新創(chuàng)建一個(gè)服務(wù)，apiserver都會(huì)在這個(gè)地址段中隨機(jī)選擇一個(gè)IP作為該服務(wù)的IP地址，而端口是事先確定的。對(duì)redis-master服務(wù)，其服務(wù)地址為11.1.1.175，端口為6379，與minion主機(jī)映射的端口也是6379。
4.2 創(chuàng)建redis-slave Pod和redis-slave服務(wù)# kubecfg -h http://172.29.88.206:8080 -c redis-slave-controller.json create replicationControllers # kubecfg -h http://172.29.88.206:8080 -c redis-slave-service.json create services
注意上面的redis-slave-controller.json有個(gè)"replicas": 2、"hostPort": 6380，因?yàn)槲覀兊募褐兄挥?個(gè)minions，如果為3的話，就會(huì)導(dǎo)致有2個(gè)Pod會(huì)調(diào)度到同一臺(tái)minion上，產(chǎn)生端口沖突，有一個(gè)Pod會(huì)一直處于pending狀態(tài)，不能被調(diào)度（可以通過(guò)日志看到原因）。
# kubecfg list pods Name Image(s) Host Labels Status ---------- ---------- ---------- ---------- -------- 2c2a06...c2971614d brendanburns/redis-slave 172.29.88.208/ name=redisslave,uses=redis-master Running 2c2ad5...c2971614d brendanburns/redis-slave 172.29.88.207/ name=redisslave,uses=redis-master Running redis-master dockerfile/redis 172.29.88.207/ name=redis-master Running # kubecfg list services Name Labels Selector IP Port ---------- ---------- ---------- ---------- -------- kubernetes component=apiserver,provider=kubernetes 11.1.1.233 443 kubernetes-ro component=apiserver,provider=kubernetes 11.1.1.204 80 redis-master name=redis-master name=redis-master 11.1.1.175 6379 redisslave name=redisslave name=redisslave 11.1.1.131 63794.3 創(chuàng)建Frontend Pod和Frontend服務(wù)
前面2步都是guestbook的redis數(shù)據(jù)存儲(chǔ)，現(xiàn)在部署應(yīng)用：(修改frontend-controller.json的replicas為2)
# kubecfg -h http://172.29.88.206:8080 -c frontend-controller.json create replicationControllers # kubecfg -h http://172.29.88.206:8080 -c frontend-service.json create services
# kubecfg -h http://172.29.88.206:8080 list pods Name Image(s) Host Labels Status ---------- ---------- ---------- ---------- ---------- 2c2a06...c2971614d brendanburns/redis-slave 172.29.88.208/ name=redisslave,uses=redis-master Running 2c2ad5...c2971614d brendanburns/redis-slave 172.29.88.207/ name=redisslave,uses=redis-master Running d87744...c2971614d kubernetes/example-guestbook-php-redis 172.29.88.207/ name=frontend,uses=redisslave,redis-master Running redis-master dockerfile/redis 172.29.88.207/ name=redis-master Running 1370b9...c2971614d kubernetes/example-guestbook-php-redis 172.29.88.208/ name=frontend,uses=redisslave,redis-master Running # kubecfg -h http://172.29.88.206:8080 list services Name Labels Selector IP Port ---------- ---------- ---------- ---------- ------ redis-master name=redis-master name=redis-master 11.1.1.175 6379 redisslave name=redisslave name=redisslave 11.1.1.131 6379 frontend name=frontend name=frontend 11.1.1.124 80 kubernetes component=apiserver,provider=kubernetes 11.1.1.233 443 kubernetes-ro component=apiserver,provider=kubernetes 11.1.1.204 80# kubecfg list replicationControllers Name Image(s) Selector Replicas ---------- ---------- ---------- ---------- frontendController kubernetes/example-guestbook-php-redis name=frontend 2 redisSlaveController brendanburns/redis-slave name=redisslave 2通過(guò)查看可知 Frontend Pod 也被調(diào)度到兩臺(tái)minion，服務(wù)IP為11.1.1.124，端口是80，映射到外面minions的端口為8000（可以通過(guò)`ps -ef|grep docker-proxy`發(fā)現(xiàn)）。 ### 4.4 其他操作（更新、刪除、查看） ## **刪除** 除此之外，你可以刪除Pod、Service，如刪除minion1上的redis-slave Pod： kubecfg -h http://172.29.88.206:8080 delete pods/2c2ad505-96fd-11e4-9c0b-000c2971614d Status ---------- Success 格式為`services/服務(wù)Name`、`pods/pods名字`，不必關(guān)心從哪個(gè)minion上刪除了。需要提醒的是，這里pods的replcas為2，所以即使刪除了這個(gè)pods，kubernetes為自動(dòng)為你重新啟動(dòng)一個(gè)。 **更新** 更新ReplicationController的Replicas數(shù)量：# docker exec -ti e5941db7e424 /bin/sh # redis-cli 127.0.0.1:6379> keys * 1) "messages" 127.0.0.1:6379> get messages ",Hi, Sean,Kubernetes,,llll,abc,xefxbfxbdxefxbfxbdxefxbfxbdxd4xb0xefxbfxbd,sync info,"把frontendController的Replicas更新為1，則這行如下命令，然后再通過(guò)上面的命令查看frontendController信息，發(fā)現(xiàn)Replicas已變?yōu)?： kubecfg -h http://172.29.88.206:8080 resize frontendController 1 **查看** Kubernetes內(nèi)置提供了一個(gè)簡(jiǎn)單的UI來(lái)查看pods、services、replicationControllers，但極其簡(jiǎn)陋，暫時(shí)可以忽略，訪問(wèn)`http://172.29.88.206:8080/static/#/groups//selector/`： ![kubernetes-simpleui][5] 在瀏覽器訪問(wèn)api：`http://172.29.88.206:8080/api/v1beta1/replicationControllers` 。 ![kubernetes-api][2] etcd做服務(wù)發(fā)現(xiàn)，可以通過(guò)api訪問(wèn)其內(nèi)容，訪問(wèn)`http://172.29.88.206:4001/v2/keys/registry/services/endpoints/default` ，得到j(luò)son格式數(shù)據(jù)。 ### 4.5 演示guestbook ## 通過(guò)上面的結(jié)果可知當(dāng)前提供前端服務(wù)的PHP和提供數(shù)據(jù)存儲(chǔ)的后端服務(wù)Redis master的Pod分別運(yùn)行在172.29.88.208和172.29.88.207上，即容器運(yùn)行在不同主機(jī)上，還有Redis slave也運(yùn)行在兩臺(tái)不同的主機(jī)上，它會(huì)從Redis master同步前端寫(xiě)入Redis master的數(shù)據(jù)。下面我們從兩方面驗(yàn)證Kubernetes能提供跨機(jī)器間容器的通信： **瀏覽器訪問(wèn)留言簿** 在瀏覽器打開(kāi)`http://${IPAddress}:8000`，IPAddress為PHP容器運(yùn)行的minion的IP地址，其暴漏的端口為8000，這里IP_Address為172.29.88.208。打開(kāi)瀏覽器會(huì)顯示如下信息： ![kubernetes-guestbook1][3] 你可以輸入信息并提交，然后Submit按鈕下方會(huì)顯示你輸入的信息： ![kubernetes-guestbook2][4] 由于前端PHP容器和后端Redis master容器分別在兩臺(tái)minion上，因此PHP在訪問(wèn)Redis master服務(wù)時(shí)一定得跨機(jī)器通信，可見(jiàn)Kubernetes的實(shí)現(xiàn)方式避免了用link只能在同一主機(jī)上實(shí)現(xiàn)容器間通信的缺陷。 **從redis后端驗(yàn)證** 我們從后端數(shù)據(jù)層驗(yàn)證不同機(jī)器容器間的通信。根據(jù)上面的輸出結(jié)果發(fā)現(xiàn)Redis slave和Redis master分別調(diào)度到兩臺(tái)不同的minion上，在172.29.88.207主機(jī)上執(zhí)行`docker exec -ti e5941db7e424 /bin/sh`，e5941db7e424 master的容器ID（`docker ps`），進(jìn)入容器后通過(guò)redis-cli命令查看從瀏覽器輸入的信息如下：
類(lèi)似可以在172.29.88.208的redis-slave上看到同樣的內(nèi)容。由此可見(jiàn)Redis master和Redis slave之間數(shù)據(jù)同步正常，OVS GRE隧道技術(shù)使得跨機(jī)器間容器正常通信。
4.6 排錯(cuò)提示所有的kubelet必須起來(lái)，否則報(bào)錯(cuò)F0319 16:56:08.058335 9960 kubecfg.go:438] Got request error: The requested resource does not exist.
必須使用-b啟動(dòng)docker，否則無(wú)法訪問(wèn)8000端口，redis-slave也沒(méi)同步
注意pods一直處于Pending或Failed狀態(tài)時(shí)去apiserver或其他組件日志里查看錯(cuò)誤，是否是由于端口綁定沖突導(dǎo)致。
參考
CentOS 7實(shí)戰(zhàn)Kubernetes部署
kubernetes-examples-guestbook
getting_started_guides-ubuntu_single_node
基于kubernetes構(gòu)建Docker集群管理詳解
原文鏈接地址：http://seanlook.com/2015/02/07/docker-kubernetes-deploy2/
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://specialneedsforspecialkids.com/yun/32421.html
摘要：部署環(huán)境及架構(gòu)操作系統(tǒng)版本版本版本服務(wù)器信息在詳細(xì)介紹部署集群前，先給大家展示下集群的邏輯架構(gòu)。其他操作更新刪除查看刪除除此之外，你可以刪除，如刪除上的格式為服務(wù)名字，不必關(guān)心從哪個(gè)上刪除了。 本文通過(guò)實(shí)際操作來(lái)演示Kubernetes的使用，因?yàn)榄h(huán)境有限，集群部署在本地3個(gè)ubuntu上，主要包括如下內(nèi)容： 部署環(huán)境介紹，以及Kubernetes集群邏輯架構(gòu) 安裝部署Open v...
摘要：年容器大火，圍繞著容器技術(shù)的發(fā)展也涌現(xiàn)了許多新項(xiàng)目。項(xiàng)目類(lèi)本節(jié)綜述了目前開(kāi)源社區(qū)和互聯(lián)網(wǎng)公司圍繞容器技術(shù)開(kāi)發(fā)的相關(guān)項(xiàng)目。是公司開(kāi)源項(xiàng)目，旨在為提供守護(hù)進(jìn)程。 2015年容器大火，圍繞著容器技術(shù)的發(fā)展也涌現(xiàn)了許多新項(xiàng)目。同時(shí)，許多老項(xiàng)目也開(kāi)始支持容器作為運(yùn)行環(huán)境。下面介紹這些項(xiàng)目： 規(guī)范標(biāo)準(zhǔn)類(lèi) 容器使用了Linux內(nèi)核的特性，Docker的成功也主要在于其充分挖掘了此類(lèi)特性。但Docke...
閱讀 739·2021-11-23 09:51
閱讀 2438·2021-10-11 11:10
閱讀 1309·2021-09-23 11:21
閱讀 1095·2021-09-10 10:50
閱讀 889·2019-08-30 15:54
閱讀 3329·2019-08-30 15:53
閱讀 3292·2019-08-30 15:53
閱讀 3189·2019-08-29 17:23
