Service服务访问
我们已经能够通过Deployment来创建一组Pod来提供具有高可用性的服务。虽然每个Pod都会分配一个单独的Pod IP，然而却存在如下两个问题：
- Pod IP仅仅是集群内可见的虚拟IP，外部无法访问。
- Pod IP会随着Pod的销毁而消失，当ReplicaSet对Pod进行动态伸缩时，Pod IP可能随时随地都会变化，这样对于我们访问这个服务带来了难度。
Service 负载均衡/Cluster IP
service是一组pod的服务抽象，相当于一组pod的LB，负责将请求分发给对应的pod。service会为这个LB提供一个IP，一般称为cluster IP 。使用Service对象，通过selector进行标签选择，找到对应的Pod:
myblog/deployment/svc-myblog.yaml
apiVersion: v1
kind: Service
metadata:
name: myblog
namespace: demo
spec:
ports:
- port: 80
protocol: TCP
targetPort: 8002 #pod对外的端口
selector:
app: myblog #匹配到此label的pod的8002端口，会加入到此k8s lb中
type: ClusterIP操作演示：
## 别名
$ #alias kd='kubectl -n demo'
## 创建服务
$ kubectl create -f svc-myblog.yaml
## 检查pod label
[root@k8s-master deployment]# kubectl -n demo get po --show-labels
NAME READY STATUS RESTARTS AGE LABELS
myblog-7fc47887f9-h5529 1/1 Running 1 44h app=myblog,pod-template-hash=7fc47887f9
myblog-7fc47887f9-k85mr 1/1 Running 1 44h app=myblog,pod-template-hash=7fc47887f9
myblog-7fc47887f9-v6qbf 1/1 Running 1 44h app=myblog,pod-template-hash=7fc47887f9
mysql-5fcb655cc9-q48f9 1/1 Running 1 47h app=mysql,pod-template-hash=5fcb655cc9
[root@k8s-master deployment]# kubectl -n demo get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
myblog ClusterIP 10.100.226.216 <none> 80/TCP 76s
#此时k8s会帮我们维护一个ENDPOINTS
[root@k8s-master deployment]# kubectl -n demo get ep
NAME ENDPOINTS AGE
myblog 10.244.0.5:8002,10.244.0.6:8002,10.244.0.7:8002 116s
$ kubectl -n demo describe svc myblog
Name: myblog
Namespace: demo
Labels: <none>
Annotations: <none>
Selector: app=myblog
Type: ClusterIP
IP: 10.100.226.216
Port: <unset> 80/TCP #lb端口
TargetPort: 8002/TCP #目的端口
Endpoints: 10.244.0.5:8002,10.244.0.6:8002,10.244.0.7:8002
Session Affinity: None
Events: <none>
# 测试扩容
$ kubectl -n demo scale deploy myblog --replicas=4
[root@k8s-master deployment]# kubectl -n demo get ep
NAME ENDPOINTS AGE
myblog 10.244.0.5:8002,10.244.0.6:8002,10.244.0.7:8002 + 1 more... 9m14sService与Pod如何关联？ service对象创建的同时，会创建同名的endpoints对象，若服务设置了readinessProbe, 当readinessProbe检测失败时，endpoints列表中会剔除掉对应的pod_ip，这样流量就不会分发到健康检测失败的Pod中
Service Cluster-IP如何访问？
$ kubectl -n demo get svc myblog
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
myblog ClusterIP 10.100.226.216 <none> 80/TCP 12m
$ curl 10.100.226.216/blog/index/为mysql服务创建service：
apiVersion: v1
kind: Service
metadata:
name: mysql
namespace: demo
spec:
ports:
- port: 3306
protocol: TCP
targetPort: 3306
selector:
app: mysql
type: ClusterIP访问mysql：
[root@k8s-master deployment]# kubectl -n demo get svc mysql
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
mysql ClusterIP 10.109.65.147 <none> 3306/TCP 4s
root@k8s-master deployment]# curl 10.109.65.147:3306
5.7.33x
l^cj��!��i%m'p|]6uE<mysql_native_password!��#08S01Got packets out of order目前使用hostNetwork部署，通过宿主机ip+port访问，弊端：
- 服务使用hostNetwork，使得宿主机的端口大量暴漏，存在安全隐患
- 容易引发端口冲突
服务均属于k8s集群，尽可能使用k8s的网络访问，因此可以对目前myblog访问mysql的方式做改造：
- 为mysql创建一个固定clusterIp的Service，把clusterIp配置在myblog的环境变量中
- 利用集群服务发现的能力，组件之间通过service name来访问
服务发现
在k8s集群中，组件之间可以通过定义的Service名称实现通信。
演示服务发现：
## 演示思路：在myblog的容器中直接通过service名称访问服务，观察是否可以访问通
# 先查看服务
$ kubectl -n demo get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
myblog ClusterIP 10.100.226.216 <none> 80/TCP 22m
mysql ClusterIP 10.109.65.147 <none> 3306/TCP 7m4s
# 查看pod
[root@k8s-master deployment]# kubectl -n demo get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
myblog-7fc47887f9-h5529 1/1 Running 1 45h 10.244.0.7 k8s-master
myblog-7fc47887f9-k85mr 1/1 Running 1 45h 10.244.0.6 k8s-master
myblog-7fc47887f9-pc24g 1/1 Running 0 15m 10.244.0.8 k8s-master
myblog-7fc47887f9-v6qbf 1/1 Running 1 45h 10.244.0.5 k8s-master
mysql-5fcb655cc9-q48f9 1/1 Running 1 2d 192.168.56.20 k8s-slave1
# 进入myblog容器
$ kubectl -n demo exec -ti myblog-7fc47887f9-h5529 bash
[root@myblog-7fc47887f9-h5529 myblog]# curl mysql:3306
5.7.33�a@zCA\;��!��&>Jn'+L|emysql_native_password!��#08S01Got packets out of order
[root@myblog-5c97d79cdb-j485f myblog]# curl myblog/blog/index/
我的博客列表
# 查看容器内dns解析
[root@myblog-7fc47887f9-h5529 myblog]# cat /etc/resolv.conf
nameserver 10.96.0.10
search demo.svc.cluster.local svc.cluster.local cluster.local www.tendawifi.com
options ndots:5
[root@myblog-7fc47887f9-h5529 myblog]# curl mysql.demo.svc.cluster.local:3306
5.7.33sYx4mnio��!��;?Q"bk3`{o;\mysql_native_password!��#08S01Got packets out of order #自动拼接的搜索域
[root@myblog-7fc47887f9-h5529 myblog]# exit
exit
# 问，这个dns是哪来的，凭什么他能提供k8s集群内的解析
[root@k8s-master deployment]# kubectl -n kube-system get po | grep core
coredns-58cc8c89f4-gnmdb 1/1 Running 7 15d
coredns-58cc8c89f4-r9hlv 1/1 Running 7 15d
实际上是k8s中的coredns组件在提供的服务
# 也是通过Service和ENDPOINTS能力对k8s内提供的服务访问
[root@k8s-master deployment]# kubectl -n kube-system get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 15d虽然podip和clusterip都不固定，但是service name是固定的，而且具有完全的跨集群可移植性，因此组件之间调用的同时，完全可以通过service name去通信，这样避免了大量的ip维护成本，使得服务的yaml模板更加简单。因此可以对mysql和myblog的部署进行优化改造：
- mysql可以去掉hostNetwork部署，使得服务只暴漏在k8s集群内部网络
- configMap中数据库地址可以换成Service（LB）名称，这样跨环境的时候，配置内容基本上可以保持不用变化
apiVersion: apps/v1
kind: Deployment
metadata: #定义资源的元数据信息
name: mysql #定义资源的名称，在同一个namespace空间中必须是唯一的
namespace: demo #定义所属ns
spec:
replicas: 1 #指定Pod副本数
selector: #指定Pod的选择器
matchLabels:
app: mysql
template:
metadata:
labels: #给Pod打label
app: mysql
spec:
#去掉此行 hostNetwork: true # 声明pod的网络模式为host模式，效果通docker run --net=host
volumes:
- name: mysql-data #容器持久化目录
hostPath:
path: /opt/mysql/data
nodeSelector: # 使用节点选择器将Pod调度到指定label的节点
component: mysql
containers:
- name: mysql
image: 192.168.56.10:5000/mysql:5.7-utf8
args:
- "--character-set-server=utf8"
- "--collation-server=utf8_general_ci" # 指定字符编码
ports: #暴露端口
- containerPort: 3306
env: #获取ns内secret中定义的值
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: myblog
key: MYSQL_USER
- name: MYSQL_PASSWD
valueFrom:
secretKeyRef:
name: myblog
key: MYSQL_PASSWD
- name: MYSQL_DATABASE
value: "myblog"
resources: #容器资源限制相关
requests:
memory: 100Mi
cpu: 50m
limits:
memory: 500Mi
cpu: 100m
readinessProbe: #容器健康检查相关
tcpSocket:
port: 3306
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 3306
initialDelaySeconds: 15
periodSeconds: 20
volumeMounts:
- name: mysql-data #容器内挂载点
mountPath: /var/lib/mysql修改configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: myblog
namespace: demo
data:
MYSQL_HOST: "mysql" # 此处替换为Service name
MYSQL_PORT: "3306"## 去除各容器污点
$ kubectl taint nodes k8s-master smoke-
node/k8s-master untainted
$ kubectl taint nodes k8s-slave1 drunk-
node/k8s-slave1 untainted
$ kubectl taint nodes k8s-slave2 perm-
node/k8s-slave2 untainted
## 更新查看configmap
$ kubectl -n demo apply -f configmap.yaml
configmap/myblog unchanged
kubectl -n demo describe configmap myblog
## 重建mysql
$ kubectl apply -f deploy-mysql.yaml
## 重新注入configmap到myblog
$ kubectl -n demo scale deploy myblog --replicas=0
$ kubectl -n demo scale deploy myblog --replicas=3
## 验证
$ kubectl -n demo exec -it myblog-7fc47887f9-5wwxs bash
[root@myblog-7fc47887f9-5wwxs myblog]# env | grep MYSQL_HOST
MYSQL_HOST=mysql服务发现实现
CoreDNS是一个Go语言实现的链式插件DNS服务端，是CNCF成员，是一个高性能、易扩展的DNS服务端。
$ kubectl -n kube-system get po -o wide|grep dns
coredns-58cc8c89f4-gnmdb 1/1 Running 7 15d 10.244.2.50 k8s-slave1
coredns-58cc8c89f4-r9hlv 1/1 Running 7 15d 10.244.2.49 k8s-slave1
# 查看myblog的pod解析配置
# 查看容器内dns解析
[root@myblog-7fc47887f9-h5529 myblog]# cat /etc/resolv.conf
nameserver 10.96.0.10
search demo.svc.cluster.local svc.cluster.local cluster.local www.tendawifi.com
options ndots:5
# 自动拼接的搜索域
[root@myblog-7fc47887f9-h5529 myblog]# curl mysql.demo.svc.cluster.local:3306
5.7.33sYx4mnio��!��;?Q"bk3`{o;\mysql_native_password!��#08S01Got packets out of order
[root@myblog-7fc47887f9-h5529 myblog]# exit
exit
## 从哪来
$ kubectl -n kube-system get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 15d
## 启动pod的时候，会把kube-dns服务的cluster-ip地址注入到pod的resolve解析配置中，同时添加对应的namespace的search域。 因此跨namespace通过service name访问的话，需要添加对应的namespace名称，匹配第二个搜索域svc.cluster.local
service_name.namespace_name
# 例如访问k8s系统级别的Service服务
[root@k8s-master deployment]# kubectl describe svc
Name: kubernetes
Namespace: default
Labels: component=apiserver
provider=kubernetes
Annotations: <none>
Selector: <none>
Type: ClusterIP
IP: 10.96.0.1
Port: https 443/TCP
TargetPort: 6443/TCP
Endpoints: 192.168.56.10:6443
Session Affinity: None
Events: <none>
# 跨namespace访问Service
[root@myblog-7fc47887f9-5wwxs myblog]# curl https://kubernetes
curl: (6) Could not resolve host: kubernetes; Unknown error
[root@myblog-7fc47887f9-5wwxs myblog]# curl -k https://kubernetes.default
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
"reason": "Forbidden",
"details": {
},
"code": 403Service负载均衡/NodePort
cluster-ip为虚拟地址，只能在k8s集群内部进行访问，集群外部如果访问内部服务，实现方式之一为使用NodePort方式。NodePort会默认在 30000-32767 ，不指定的会随机使用其中一个。
myblog/deployment/svc-myblog-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
name: myblog-np
namespace: demo
spec:
ports:
- port: 80
protocol: TCP
targetPort: 8002
selector:
app: myblog
type: NodePort查看并访问服务：
$ kubectl -n demo create -f svc-myblog-nodeport.yaml
service/myblog-np created
$ [root@k8s-master deployment]# kubectl -n demo get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
myblog ClusterIP 10.100.226.216 <none> 80/TCP 87m
myblog-np NodePort 10.103.170.13 <none> 80:31728/TCP 16s
mysql ClusterIP 10.109.65.147 <none> 3306/TCP 72m
#集群内每个节点的NodePort端口都会进行监听
[root@k8s-master deployment]# netstat -lntup | grep 31728
tcp6 0 0 :::31728 :::* LISTEN 3179/kube-proxy
[root@k8s-slave1 ~]# netstat -lntup | grep 31728
tcp6 0 0 :::31728 :::* LISTEN 2339/kube-proxy
[root@k8s-slave2 ~]# netstat -lntup | grep 31728
tcp6 0 0 :::31728 :::* LISTEN 1909/kube-proxy浏览器访问
kube-proxy
运行在每个节点上，监听 API Server 中服务对象的变化，再通过创建流量路由规则来实现网络的转发。参照
参见：官方文档
有三种模式：
- User space, 让 Kube-Proxy 在用户空间监听一个端口，所有的 Service 都转发到这个端口，然后 Kube-Proxy 在内部应用层对其进行转发 ， 所有报文都走一遍用户态，性能不高，k8s v1.2版本后废弃。
- Iptables， 当前默认模式，完全由 IPtables 来实现， 通过各个node节点上的iptables规则来实现service的负载均衡，但是随着service数量的增大，iptables模式由于线性查找匹配、全量更新等特点，其性能会显著下降。
- IPVS， 与iptables同样基于Netfilter，但是采用的hash表，因此当service数量达到一定规模时，hash查表的速度优势就会显现出来，从而提高service的服务性能。 k8s 1.8版本开始引入，1.11版本开始稳定，需要开启宿主机的ipvs模块。
iptables模式示意图： 
流量转发路径抓取
$ iptables-save |grep -v myblog-np|grep "demo/myblog"
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.100.226.216/32 -p tcp -m comment --comment "demo/myblog: cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.100.226.216/32 -p tcp -m comment --comment "demo/myblog: cluster IP" -m tcp --dport 80 -j KUBE-SVC-WQNGJ7YFZKCTKPZK
$ iptables-save |grep KUBE-SVC-WQNGJ7YFZKCTKPZK
:KUBE-SVC-WQNGJ7YFZKCTKPZK - [0:0]
-A KUBE-SERVICES -d 10.100.226.216/32 -p tcp -m comment --comment "demo/myblog: cluster IP" -m tcp --dport 80 -j KUBE-SVC-WQNGJ7YFZKCTKPZK
-A KUBE-SVC-WQNGJ7YFZKCTKPZK -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-3T3R7W52EDXE5YWP
-A KUBE-SVC-WQNGJ7YFZKCTKPZK -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-4P46YSTS2B3EDKRW
-A KUBE-SVC-WQNGJ7YFZKCTKPZK -j KUBE-SEP-RZRWFU3D4FSY742B
$ iptables-save |grep KUBE-SEP-4P46YSTS2B3EDKRW
:KUBE-SEP-4P46YSTS2B3EDKRW - [0:0]
-A KUBE-SEP-4P46YSTS2B3EDKRW -s 10.244.1.22/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-4P46YSTS2B3EDKRW -p tcp -m tcp -j DNAT --to-destination 10.244.1.22:8002
-A KUBE-SVC-WQNGJ7YFZKCTKPZK -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-4P46YSTS2B3EDKRW
$ iptables-save |grep KUBE-SEP-3T3R7W52EDXE5YWP
:KUBE-SEP-3T3R7W52EDXE5YWP - [0:0]
-A KUBE-SEP-3T3R7W52EDXE5YWP -s 10.244.0.9/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-3T3R7W52EDXE5YWP -p tcp -m tcp -j DNAT --to-destination 10.244.0.9:8002
-A KUBE-SVC-WQNGJ7YFZKCTKPZK -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-3T3R7W52EDXE5YWPIngress服务访问
对于Kubernetes的Service，无论是Cluster-Ip和NodePort均是四层的负载，集群内的服务如何实现七层的负载均衡，这就需要借助于Ingress，Ingress控制器的实现方式有很多，比如nginx, Contour, Haproxy, trafik, Istio，我们以nginx的实现为例做演示。
Ingress-nginx是7层的负载均衡器 ，负责统一管理外部对k8s cluster中service的请求。主要包含：
- ingress-nginx-controller：根据用户编写的ingress规则（创建的ingress的yaml文件），动态的去更改nginx服务的配置文件，并且reload重载使其生效（是自动化的，通过lua脚本来实现）；
- ingress资源对象：将Nginx的配置抽象成一个Ingress对象，每添加一个新的Service资源对象只需写一个新的Ingress规则的yaml文件即可（或修改已存在的ingress规则的yaml文件）
示意图： 
实现逻辑
- ingress controller通过和kubernetes api交互，动态的去感知集群中ingress规则变化
- 然后读取ingress规则(规则就是写明了哪个域名对应哪个service)，按照自定义的规则，生成一段nginx配置
- 再写到nginx-ingress-controller的pod里，这个Ingress controller的pod里运行着一个Nginx服务，控制器把生成的nginx配置写入/etc/nginx.conf文件中
- 然后reload一下使配置生效。以此达到域名分别配置和动态更新的问题。
Ingress安装
参见：官方文档
#这里我们将Ingres调度到 slave1（192.168.56.20）部署
# 给slave2打上对应的标签
$ kubectl label node k8s-slave1 ingress=true
node/k8s-slave1 labeled
# 安装
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml
或者使用myblog/deployment/ingress/mandatory.yaml
...
212 spec:
213 hostNetwork: true #添加为host模式
214 # wait up to five minutes for the drain of connections
215 terminationGracePeriodSeconds: 300
216 serviceAccountName: nginx-ingress-serviceaccount
217 nodeSelector:
218 ingress: "true"
219 containers:
...
安装ingress
$ kubectl create -f mandatory.yaml
$ kubectl -n ingress-nginx get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-ingress-controller-766b7d9f4-bprq8 1/1 Running 0 7s 192.168.56.20 k8s-slave1
# 添加ingress对象
$ vi myblog/deployment/ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: myblog
namespace: demo
spec:
rules:
- host: test.cakepanit.com
http:
paths:
- path: /
backend:
serviceName: myblog
servicePort: 80
$ kubectl create -f ingress.yaml
# 修改本机hosts（mac系统）
$ felix@MacBook ~ % sudo vim /etc/hosts
Password:
felix@MacBook ~ % cat /etc/hosts
192.168.56.20 test.cakepanit.com访问测试
ingress-nginx动态生成upstream配置
$ kubectl -n ingress-nginx get po
$ kubectl -n ingress-nginx exec -it nginx-ingress-controller-766b7d9f4-bprq8 bash
$ cat nginx.conf
...
server {
server_name test.cakepanit.com ;
listen 80 ;
listen [::]:80 ;
listen 443 ssl http2 ;
listen [::]:443 ssl http2 ;
set $proxy_upstream_name "-";
ssl_certificate_by_lua_block {
certificate.call()
}
location / {
...HTTPS访问：
#自签名证书
$ openssl req -x509 -nodes -days 2920 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=*.devops.cn/O=ingress-nginx"
# 证书信息保存到secret对象中，ingress-nginx会读取secret对象解析出证书加载到nginx配置中
$ kubectl -n demo create secret tls https-secret --key tls.key --cert tls.crt修改yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: myblog-tls
namespace: demo
spec:
rules:
- host: test.cakepanit.com
http:
paths:
- path: /
backend:
serviceName: myblog
servicePort: 80
tls:
- hosts:
- test.cakepanit.com
secretName: https-secret然后，访问 https://test.cakepanit.com/admin/
