kubernetes存储&Service
Service
Service也是Kubernetes里的最核心的资源对象之一，Kubernetes里的每个Service其实就是我们经常提起的微服务架构中的一个“微服务”，之前我们所说的Pod、RC等资源对象其实都是为这节所说的“服务”------Kubernetes Service作“嫁衣”的。
Pod、RC与Service的关系
Kubernetes的Service定义了一个服务的访问入口地址，前端的应用（Pod）通过这个入口地址访问其背后的一组由Pod副本组成的集群实例，Service与其后端Pod副本集群之间则是通过Label
Selector来实现“无缝对接”的。而RC的作用实际上是保证Service的服务能力和服务质量始终处于预期的标准。
通过分析、识别并建模系统中的所有服务为微服务-----Kubernetes Service，最终我们的系统由多个提供不同业务能力而又彼此独立的微服务单元所组成，服务之间通过TCP/IP进行通信，从而形成了我们强大而又灵活的弹性网格，拥有了强大的分布式能力、弹性扩展能力、容错能力，于此同时，我们的程序架构也变得简单和直观许多，
Service 代理
userspace 代理模式
这里的userspace是指Linux操作系统的用户空间。这种模型中，Kube-proxy负责跟踪API Server上的service和Endpoints对象的的变动（创建或移除）。对于每个service对象它会打开一个本地端口（运行于用户空间的Kube-proxy进程负责监听），任何到达此代理端口的连接请求都会被代理至当前Service资源后端的各Pod对象上，至于会挑选哪个pod取决于service资源的调度方式，默认为轮询
iptables 代理模式
iptables代理模式和前一种代理模式是类似的，都是由Kube-proxy来跟踪监听API-server上的service和Endpoints的变更。但是有一点不同的是iptables规则直接捕获到达cluster IP和port的流量，并将其重定向至当前Service的后端，对于每个Endpoints对象，Service资源会为其创建iptables规则并关联至挑选的后端pod资源，默认算法是随机调度（random）。iptables代理模式在Kubernetes1.1版本引入，并在1.2版开始成为默认类型。
ipvs 代理模式
ipvs是建立在netfilter的钩子函数上，但它使用hash表作为底层数据结构并工作于内核空间，因此流量转发速度特别快、规则同步性很好，而且它支持众多调度算法，rr（轮询）、lc（最小连接数）、dh（目标哈希）、sh（源哈希）、sed(最短期望延迟)、nq（不排队调度）。
内部访问方式
ClusterIP 服务是 Kubernetes的默认服务。它给你一个集群内的服务，集群内的其它应用都可以访问该服务。集群外部无法访问它。在某些场景下我们可以使用 Kubernetes 的Proxy 模式来访问服务，比如调试服务时。
创建Service
Service从逻辑上代表了一组Pod,具体是哪些Pod则是
由label来挑选的。Service有自己的IP,而且这个IP是不变的。客户端只需要访问Service的IP,Kubernetes则负责建立和维护Service与Pod的映射关系。无论后端Pod如何变化,对客户端不会有任何影响,因为Service没有变
创建Deployment
cat httpd.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: httpd
spec:
replicas: 3
selector:
matchLabels:
run: httpd
template:
metadata:
labels:
run: httpd
spec:
containers:
- name: httpd
image: httpd
ports:
- containerPort: 80
注意的是：node节点上的docker服务必须是好的，而且虚拟机要能上网
kubectl apply -f httpd.yml
kubectl get pod -o wide #注意：ip的出现是需要时间的(容器的准备也是需要时间的)
我们可以看到的是：Pod分配了各自的IP,这些IP只能被Kubernetes Cluster中的容器和节点访问
创建Service
cat httpd-svc.yml
apiVersion: v1
kind: Service
metadata:
name: httpd-svc
spec:
selector:
run: httpd
ports:
- protocol: TCP
port: 8080
targetPort: 80
#v1是Service的apiVersion
#指明当前资源的类型为Service
#Service的名字为httpd-svc
#selector指明挑选那些label为run: httpd的Pod作为Service的后端
#将Service的8080端口映射到Pod的80端口,使用TCP协议
kubectl apply -f httpd-svc.yml
kubectl get service
httpd-svc分配到一个CLUSTER-IP
以通过该IP 访问后端的httpd Pod
通过kubectl describe可以查看httpd-svc与Pod的对应关系
kubectl describe service httpd-svc
service运行原理
Cluster IP是一个虚拟IP,是由Kubernetes节点上的iptables规则管理的可以通过iptables-save命令打印出当前节点的iptables规则,因为输出较多,这里只截取与httpd-svc Cluster IP 10.99.229.179相关的信息
注意用户的切换：此处使用root用户
iptables-save |grep httpd-svc
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.104.247.136/32 -p tcp -m comment --comment "default/httpd-svc: cluster IP" -m tcp --dport 8080 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.104.247.136/32-p tcp -m comment --comment "default/httpd-svc: cluster IP" -m tcp --dport 8080 -j KUBE-SVC-RL3JAE4GN7VOGDGP
如果Cluster内的Pod(源地址来自10.244.0.0/16)要访问httpd-svc,则允许其他源地址访问httpd-svc,跳转到规则KUBE-SVC-RL3JAE4GN7VOG DGP。KUBE-SVC-RL3JAE4GN7VOGDGP规则
iptables-save |grep KUBE-SVC-RL3JAE4GN7VOGDGP
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-N5PH4BBCFTMHGLV6
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-UEWSDQT52CMKBNNL
-A KUBE-SVC-RL3JAE4GN7VOGDGP -j KUBE-SEP-BSPNJWUG33XKKPE5
1/3的概率跳转到规则 KUBE-SEP-N5PH4BBCFTMHGLV6
1/3的概率(剩下2/3的一半)跳转到规则 KUBE-SEP-UEWSDQT52CMKBNNL
1/3的概率跳转到规则 KUBE-SEP-BSPNJWUG33XKKPE5
即将请求分别转发到后端的三个Pod。通过上面的分析,我们得到结论:iptables将访问Service的流量转发到后端Pod,而且使用类似轮询的负载均衡策略
另外,需要补充一点:Cluster的每一个节点都配置了相同的
iptables规则,这样就确保了整个Cluster都能够通过Service的Cluster IP访问Service
DNS访问Service
在Cluster中,除了可以通过Cluster IP访问Service,Kubernetes还提供了更为方便的DNS访问
kubeadm部署时会默认安装kube-dns组件
kube-dns是一个DNS服务器。每当有新的Service被创建,kube-dns会添加该Service的DNS记录。Cluster中的Po可以通过<SERVICE_NAME>.<NAMESPACE_NAME>访问Service
如果要访问其他namespace中的Service,就必须带上namesapce了。kubectl get namespace查看已有的namespace
kubectl get namespace
kube-dns是一个DNS服务器。每当有新的Service被创建,kube-dns会添加该Service的DNS记录
ku
最低0.47元/天 解锁文章
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
