-
Kubernetes
Service
服务发布实践
1
eBay
自
2014
年
末
开
始
Kubernetes
的
落
地
工
作
，
并
在
2015
年
扩
大
研
发
投
入
。
目
< br>前
Kubernetes
已
经<
/p>
部
署
在
eBay
的
生
产
环
境
，
并
将
作
为
下
一
代
云
计
算
< br>平
台
。
本
文
结
合
社
区
Kubernetes
的
设
计
和
实
现
，
并
结
合
OpenStack
云
基
础
架
构
，
深
入
分
析
Kubernet
es
服
务
部
署
的
设
计
与
实
现
。
如
果
您
在
寻
找
服
务
发
< br>布
的
方
案
或
者
在
寻
找
Kubernetes
服
务
相
关
的
模
块
的
原
理
或
行
为
，
阅
读
本
文
会<
/p>
让
你
有
比
较
明
确
的
方
向
。
总揽
Ku
bernetes
架
构
下图是
Kubernetes
的架构图，当用户将应用从传统平台转移至
Kubernetes
时，首当其冲的任务就是将应用容器化，并定
义
Pod
和
ReplicaSet
（
或者
PetSets
，
如果迁移的是有
状态应用）
来运行应用，
Kubernetes
提供针对应用的
PDMR
（
P
rovision
、
Deployment
、
Monitoring
、
Rem
ediation
）
。通常来讲，
Ku
bernetes
为
Pod
分配的是私
有
IP
。如果需要提供应用的跨集
群访
问，则需要通过
Service
以及
I
ngress
来实现。
2
<
/p>
服
务
的
发
布
下
图
展
示
的
是
Kubernetes
集
群
包
括
集
群<
/p>
联
邦
中
服
务
相
关
的
组
件
以
及
组
件
之
间
的
关
系
。
Federated-apiserver
< br>作
为
集
群
联
邦
推
荐
的
面
向
用
户
的
接
口
，
接
受
用
户
请
求
，
并
< br>根
据
联
邦
层
面
的
调
度
器
和
控
制
器
，
将
用
户
请
求
分
裂
/
转
发
< br>至
Kubernetes
集
群<
/p>
。
根据用户
IaaS
环境的不同，可能需要采用不同的
Provider
来实现与外部组件的整合，目前这些定制化
Provider
包括：
3
?
DNS Provider
：
社
区
实
现
包
括
GEC Google
DNS
、
AWS DNS
，
eBay
采
用
自
己
的
GTM
client
。
?
Load
Balancer
provider
for
service
：
主
流
云
平
台
都
有
自
己
的
Provider
，
eBay
的
Kubernetes
部
署
在
OpenStack
之
上
，
采
用
社
区
版
本
的
OpenStack
Provider
。
?
Load Balancer
provider for ingress
：
社
区
目
前
有
< br>GCLB
和
Nginx
两
个
版
本
的
Ingress
Controller
，
eBay
与
自
己
的
内
部
load
balancer
management
< br>system
（
LBMS
）
对
接
，
采
用
自
己
订
制
的
基
于
< br>LBMS client
的
Ingress
Controller
。
4
关
于
Kub
ernetes
的
基
本
概
念
如
Pod
、
Service
等
，
网
上
有
很
多
相
关
文
章
，
可
以
参
考
Kubernetes
官
网
或
网
上
的
入
门
文
章
，
本
文
< br>不
再
一
一
赘
述
。
本
文
希
望
针
对
Kubernetes
服
务
发
布
，
进
行
end
to end
的
分
析
，
并
针
对
特
定
云
环
境
如
eBay
采
用
的
< br>OpenStack
的
具
体
实
践
。
服务发布
5
<
/p>
第
一
步
：
定
义
你
的
服
务
eBay
很
多
应
用
都
采
用
< br>微
服
务
架
构
，这
使
得
在
大
多
数
情<
/p>
况
下
，作
为
服
务
所
有
者
，除
了
实
现
业
务
逻
辑
以
外
，
还
需
要
考
虑
如
何
把
服<
/p>
务
发
布
到
Kubernetes
集
群
< br>或
者
集
群
外
部
，
使
这
些
服
务
能
够
被
Kubernetes
应
用
，
其
他
Kubernetes
集
群
的
应
用
以
及
外
部
应
用
使
用
。
< br>
这
是
一
个
业
界
的
通
用
需
求
，
因
此
Kuber
netes
提
供
了
灵
活
的
服
务
发
布
方
式<
/p>
，
用
户
可
以
通
过
Servic
eType
来
指
定
如
何
来
发
布
服
务
。
?
Clu
sterIP
：
此
类
< br>型
是
默
认
的
，
这
种
类
型
的
服
务
只
能
在
集
群
内
部
访
问
。
?
NodePort
：
此
类
型
同
时
会
分
配
ClusterIP
，
并
进
一
步
在
集
群
所
有
节
点
的
同
一
端
口
上
曝<
/p>
露
服
务
，
用
户
可
以
通
过
任
意
的
访
问
服
务
。
?
LoadBalanc
er
：
此
类
型
同
时
会
分
配
ClusterIP
，
< br>分
配
NodePort
，
并
且
通
过
Cloud
Provider
来
实
现
LB
设
< br>备
的
配
制
，并
且
在
LB
设
备
中
配
置
中
，将
作
为
pool member<
/p>
，
LB
设
备
依
据
转
发
规
则
将
流
量
转
到
节
< br>点
的
NodePort
。
内
部
服
务
ClusterIP
如
果
你
的
Service<
/p>
只
服
务
于
Cluster
内
部
，
那
么
ServiceType
定
义
为
Cluste
rIP
就
足
够
了
。
6
Kube-proxy
是运行在
Kubernetes
集群所有节点的组件，
它的主要职责是实现服务的虚拟
IP
。
针对只面向集群内部的服务，
我们建议用户使用
Cluste
rIP
作为服务类型，该类型比
nodePort
少占用节点端口，并比
LoadBalancer
类
型减少对
LB
设
备的访问，我们应该尽
可能的避免不必要的
LB
设备的访问，因为任何外部依赖都有失
败的可能性。
外
< br>部
服
务
NodePort
针对类型是”
NodePort
”
< br>的服务，
Kubernetes Master
会从与定
义的端口范围内请求一个端口号
（默认范围：
30000-32
767
）
，
每个节点会把该端口的流量
转发到对应的服务，
端口号会先是在服务的
[*].nodeP
ort
。
如果你希望指定端口，
你
可以通过
nodePort
来定义端口号，
系统会检查该端口是否可用，
如果可用就分配该指定端口。
指定端口时需要考虑端口冲
突，并且端口需要在预定义的范围内。<
/p>
这
为
开
发
者
提
供
了
自
由
度
，他
们
可
< br>以
配
制
自
己
的
LB
设
备
，配
制
未
被
Kubernetes
完
全
支
持
的
云
环
境
，
直
接
开
放
一
个
或
者
多
个<
/p>
节
点
的
IP
供
用
户
访
问
服
务
。
eBay
的
Kubernetes
集
群
架
设
在
OpenStack
环
境
之
上
，
采
用
OpenStac
k
VM
作
为
Kubernetes Node
，
这
些
Node
在
隔
离
的
VPC
，
无
法
直
接
访
问
，
因
此
对
外
不
采
用
nodePort
方
式
发
布
服
务<
/p>
。
LoadBalancer
针
对
支
持
外
部
LB
设
备
的
Cloud
Provider
的
情
况
，
将
Type
字
段
< br>设
置
为
LoadBalance
r
会
为
服
务<
/p>
通
过
异
步
调
用
生
成
负
载
均
衡
配
制
，
负
载
均
衡
配
制
会
体
现
在<
/p>
服
务
的
lanc
er
字
段
。
7
<
/p>
实
际
上
，
当
此
类
型
的
服
务
进
行
Load
Balancer
配
置
时
，
n
odeip
：
nodeport
作
为
LB
P
ool
的
member
，
最
终
的
traffic
还
是
转
到
某
node
的
node
Port
上
的
。
因
为
e
Bay
有
OpenStack
作
为
IaaS
层
架
构
，
每
个
OpenStack
AZ
有
< br>专
属
的
负
载
均
衡
设
备
，
负
载
均
衡
设
备
与
虚
拟
机
（
即
Kubernetes
Node
）
的
连
通
性
在
OpenStack
AZ<
/p>
创
建
的
时
候
就
已
经
设
置
好
，
并
且
OpenStack
的<
/p>
LBaaS
已
经
把
针
对
LB
设
备
的
操
作
做
了
抽
象
，
这
让
Kuberne
tes
和
LB
设
备
的
通
信
变
得
非
常
简
单
。
eBay
直<
/p>
接
采
用
社
区
版
本
的
OpenStack
Provider
作
为
Cloud Provider
，
该
Provider
会
调
用
OpenStack LBaaS API
来
进
行
LB
< br>设
备
的
配
制
，
无
需
订
制
即
可
实
现
与
LB
设
备
的
集
成
。
Service
Controller
：
服
务
是
如
何
被
发
布
到
集
< br>群
外
部
的
Kubernetes
controller
manager
的
主
要
作
用
是
watch
kube-apise
rver
的
相
关
对
象
，
在
有
新
对
象
事
件
如
创
建
，
更
新
和
删
除
发
生
< br>时
，
进
行
相
应
的
配
制
，
如
ServiceControll
er
的
主
要
作
用
是
为
Ser
vice
配
制
负
载
均
衡
，
R
eplicaSetController
主
要
作
用
是
管
理
Replicaset
中
定
义
的
Pod
，
保
证
Pod
与
Replicas
一
致
。
如
果
你
对
Kubernetes
代
码
比
较
熟
悉
，
你
会
发
< br>现
ServiceController
是
其
中
职
责
< br>相
对
清
晰
，
代
码
相
对
简
单
的
一
个
控
制
器
。
通
过
解
读
ServiceCo
ntroller
的
源
码
，
我
们
可
< br>以
了
解
到
ServiceController
同
时
< br>监
控
Service
和
Node
两
种
对
象
的
变
化
，
针
对
任
何
新
创
建
或
者
更
新
的
服
务
，
Se
rviceController
调
用
Load
Balancer Provider
的
接
口
来
实
现
Load Balancer
的
配
制
。
因
为
Load Balancer
的
me
mber
是
Cluster
中
所
有
的
Ready <
/p>
Node
，
所
以
当
有
任
何
Node
的
变
化<
/p>
时
，
我
们
需
要
重
新
配
制
所
有
8
的
LoadBalancer
Poo
l
以
体
现
这<
/p>
种
变
化
，
这
也
就
是
ServiceController
要
同
时
监
控
Node
对
象
的
原
因
。
下
图
展
示
< br>的
是
当
ServiceCont
roller
调
用
OpenStack
LB Provider
时
所
做
的
操
作
的
时
序
图
。
所
以
最
终
的
配
置
结
果<
/p>
是
针
对
每
个
Service
的
Port
，
在
LB
设
备
上
会
创
建
一
个
Lo
ad
Balancer
Pool
，
VIP
可
以
接
受
外
部
请
求
，
Pool Member
是
节
点
IP
加
nodePort
。
LB<
/p>
设
备
和
Node
（
即
OpenStack VM
）
处
于
同
一
个
Availability Zone
和
VPC
，
其
连
通
性
在
Availability Zone
创
建
时
即
得
到
保
证
。
物
理
上
，
LB
< br>设
备
和
虚
拟
机
所
在
的
物
理
机
通
过
路
由
连
接
，
路
由
规
则
保
证
< br>LB
设
备
对
特
定
IP
段
的
VM
可
见
。
9
这样的配制结果保证
VIP
接受到的所有
traffic
，能够根据
LB
设备的规则，跳转到
Kubernete
s Node
的
nodePort
。<
/p>
为
什
么
用
NodeIP
:nodePort
作
为
LB mem
ber
，
如
果
一
个
Cluster
规
模
较
大
，
如
几
千
个
Node
，
LB pool
会
不
会
很
大
，
为
什
么
< br>不
用
Pod IP
作
为
LB
？
1.
LB
和
VM
之
间<
/p>
的
路
由
规
则
配
制
只
包
含
VM
IP
段
，
在
AZ
部
署
的
时
候
创
建
。
Pod
IP
在
通
常
情
况
下
是
不
同
的
range
，
与
LB
< br>之
间
无
法
直
接
相
通
。
采
用
Node
IP
作
为
Pool
member
使
得
底
层
架
构
OpenSta
ck
的
配
制
和
Kubernetes
的
配
制
分
离
开
来
，
不
用
考
虑
Pod
的
IP
范
围
划
定
。
2.
Node
的
变
化
相
对
Pod
而
言
较
少
，<
/p>
这
样
可
以
减
少
对
LB
设
备
的
访
问
，
LB
可
能
会
出
错
< br>。
3.
LB Service Type
是
基
于
Node Port Type
的<
/p>
，
Service
同
时
提
供
两
种
访
问
方
式<
/p>
。
4.
集
群
中
每
个
节
点
被
轮
询
到
的
< br>机
会
均
等
，
这
使
得
每
个
节
点
需
要
解
析
iptab
les
的
机
会
一
致
，
进
而<
/p>
使
iptables
解
< br>析
在
每
台
机
器
的
资
源
需
求
一
致
，
避
免
某
些
节
点
因
为
iptable
rules
10
解
析
导
致
压
力
过
大
的
可
能
性
。
（
与
< br>谷
歌
首
席
软
件
工
程
师
Tim
Hockin
面
对
面
讨
论
< br>过
此
事
）
kube-proxy
：接好最
后一棒，从
Node
到
Pod
11
我
们
知
道
，
Kuber
netes
服
务
只
是
把
应
用
对
外
提
供
服<
/p>
务
的
方
式
做
了
抽
象
，
真
正
的
应
用
跑
在
Pod
的
成
员
Container
里
，
我
们
通
过
LB
设
备
已
经
把
提
交
至
< br>VIP
的
请
求
< br>转
到
Kubernetes
N
odes
对
应
的
nodePort
上
，
那
么
nodePort
上
的
请
求
是
如
何
进
一
步
转
到
提
供
后
台
服
务
< br>的
Pod
的
呢
< br>？
Kube-proxy is the secret sauce
，
我
们
来
看
看
kube-proxy
都
做
了
什
么
。
目
前
kube-proxy
支
持
两
种
模
式
，
userspace<
/p>
和
iptables
，
< br>iptables
模
式
因
为
不
需
要
userspace
和
kernel
space
的
切
换
，
在
数
据
转
发
上
有
更
高
的
效
率
。
所
以
从
1.2
版
本
开
始
，
iptables
是
默
认
模
< br>式
，
只
有
当
kernel
版
本
不
支
持
iptables
时
，
userspace
< br>模
式
才
需
要
被
启
用
。
Kubernetes
只操作了
Filter
和
Nat
表。
Filter
在
该
表
中
，一
个
基
本
原
则
是
只
过
滤
数
据
包
而
不
修
改
他
们
。
filter ta
ble
的
优
势
是
小
而
快
，可
以
hook
到
input
，
output
和
forward
。
这
意
味
着
针
对
任
何
给
定
的
数
据
包
，
只
有
可
< br>能
有
一
个
地
方
可
以
过
滤
它
。
NAT
此
表
的
主
要
作
用
是
在
PREROUTING
和
POSTROUNTING
的
钩
子
中
，
修
改
目
标
地
址
和
原
地
址
。
与
filter
表
稍
有
不
同
的
是
，
该
表
中
只
有
新
连
接
的
第
一
个
包
会<
/p>
被
修
改
，
修
改
的
结
果
会
自
动
apply
到
同
一
连
接
的
后
续
包
中
。
12
下面是基于
iptables
chain
的数据包流向图
基
于
ipt
ables
的
kube-proxy
的
实
现
代
码
在
pkg/proxy/iptables/
，
其
主
要
职
责
包
括
两
大
块
，
一
块
是
侦
听
Service
更
新
事
件
，
并
更
新
Service
相
关
的
iptables
规
则
，
一
块
是
侦
听
Endpoint
更
新
事
件
，
更
新
Endpoint<
/p>
相
关
的
ipta
bles
规
则
，
将
包
请
求
转
入
Endpoint
对
应
的
Pod
，
如
果
某
个
Service
尚
没
有
Pod
创
建
，
那
么
针
对
此
Service
的
请
求
将
会
被
drop
掉
。
13
kube-proxy
对
iptabl
es
的
链
进
行
了
扩
充
，
自
定
义
了
KUBE-SERVICES
，
KUBE-
NODEPORTS
，
KUBE-
POSTROUTING
，
KUBE-MARK-
MASQ
和
KUBE-MARK-DROP
五
个
链
，
并
主
要
通
过<
/p>
为
KUBE-SERVICES chain
增
加
rule
来
< br>配
制
Routing Traffic
< br>规
则
。
我
们
可
以
通
过
对
照
源
码
和
iptables
规
则
表<
/p>
，
来
分
析
针
对
下
面
的
Service
信
息<
/p>
，
Kubernetes
做
了
怎
么
样
< br>的
iptables
配
制
。
kubectl get svc es1 -o yaml
apiVersion: v1
kind: Service
metadata:
creationTimestamp: 2016-08-26T05:03:38Z
labels:
component:
elasticsearch
name: es1
namespace: default
resourceVersion:
selfLink:
/api/v1/namespaces/default/services/es1
uid:
72f28428-6b4a-11e6-887a-42010af00002
spec:
clusterIP:
10.0.147.93
ports:
- name:
http
nodePort: 32135
port: 9200
protocol: TCP
targetPort: 9200
selector:
component: elasticsearch
sessionAffinity: None
type:
LoadBalancer
status:
loadBalancer:
ingress:
- ip: 104.197.138.206
kubectl get
endpoints es1
14
NAME ENDPOINTS
AGE
es1 10.180.2.11:9200
11d
在
iptables
表
中
，
通
过
iptables-save
< br>可
以
看
到
在
Nat
表
中
创
建
好
的
这
些
链
。
:KUBE-MARK-DROP - [0:0]
/*
对于未能匹配到跳转规则的
traffic set
mark 0x8000
，有此标记的数
据包会在
filter
表
drop
掉
*/
:KUBE-MARK-MASQ - [0:0]
/*
对于符合条件的包
set mark 0x4000,
有此标记的数据包会在
KUBE-POSTROUTING
chain
中统一做
MASQUERADE*/
:KUBE-NODEPORTS - [0:0] /*
针对
通过
nodeport
访问的
pack
age
做的操作
*/
:KUBE-
POSTROUTING - [0:0]
:KUBE-SERVICES -
[0:0] /*
操作跳转规则的主要
chain*/
为
默
认
的
PREROUTING
，
Output
和
POSTROUTI
NG chain
增
加
规
则
，
跳
转
< br>至
Kubernetes
自
定<
/p>
义
的
新
chai
n
。
-A
PREROUTING -m comment --comment
-j
KUBE-SERVICES
-A OUTPUT -m comment
--comment
-j KUBE-SERVICES
-A POSTROUTING -m comment --comment
rules
对
于
KUBE-MARK-MASQ<
/p>
链
中
所
有
规
则
设
置
了
Kubernetes
独
有
MARK
标
记
，
在
KUBE-POSTROUTING
< br>链
中
对
NODE
节
点
上
匹
配
Kubernetes
独
有
MARK
标
记
的<
/p>
数
据
包
，
进
行
SNAT
处
理
。
-A KUBE-MARK-MASQ -j MARK --set-xmark
0x4000/0x4000
15