K8s暴露内部服务的多种方式

hostNetWork:true

测试yaml：

apiVersion: v1
kind: Pod
metadata:
  name: nginx-hostnetwork
spec:
  hostNetwork: true
  containers:
  - name: nginx-hostnetwork
    image: nginx:1.7.9

# 创建pod并测试
$ kubectl create -f nginx-hostnetwork.yaml
$ kubectl get pod --all-namespaces -o=wide | grep nginx-hostnetwork
default       nginx-hostnetwork                                1/1     Running   0          15m     172.30.3.222   k8s-n3   <none>           <none>
# 测试
$ curl http://k8s-n3
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
... ...

HostPort

测试yaml：

apiVersion: v1
kind: Pod
metadata:
  name: nginx-hostport
spec:
  containers:
  - name: nginx-hostport
    image: nginx:1.7.9
    ports:
    - containerPort: 80
      hostPort: 8088

# 创建pod并测试
$ kubectl create -f nginx-hostnetport.yaml
$ kubectl get pod --all-namespaces -o=wide | grep nginx-hostport
default       nginx-hostport                                   1/1     Running   0          13m     10.244.4.9     k8s-n3   <none>           <none>
# 测试
$ curl http://k8s-n3:8088
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
... ...

Port Forward

端口转发利用的是Socat的功能，这是个神奇的工具，你值得拥有：Socat

# 当前机器必须配置有目标集群的kubectl config
# 测试本地机器8099端口转发到目标nginx-hostnetwork 80端口
$ kubectl port-forward -n default nginx-hostnetwork 8099:80
# 测试，本地访问localhost:8099
$ curl http://localhost:8099
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
... ...

Service

之前都是直接将pod上的应用暴露出去，这种方式在实际的生产环境中基本不可取，标准的搞法是基于Service。

Service有三种类型：ClusterIP、NodePort、LoadBalancer。

首先，先了解下Service中端口的概念：

port/nodeport/targetport

k8s的端口分类和详解.jpg

port——Service暴露在Cluster IP上的端口，也就是虚拟IP要绑定的端口。port是提供给集群内部客户端访问Service的入口。

nodeport——K8s集群暴露给集群外部客户访问Service的入口。

targetport——是Pod内容器的端口。从port和nodeport上进入的数据最终会经过Kube-proxy流入到后端pod里容器的端口，如果targetport没有显示声明，那么会默认转发到Service接受请求的端口（和port端口保持一致）。

通过Service暴露内部服务的方式有四种：ClusterIP、NodePort、LoadBalancer、Ingress

ClusterIP

ClusterIP其实是Service的缺省类型，就是默认类型，例如之前部署的dashboard插件其实就使用是这种类型，可以通过如下指令来分辨：

$ kubectl -n kube-system get svc kubernetes-dashboard -o=yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"k8s-app":"kubernetes-dashboard"},"name":"kubernetes-dashboard","namespace":"kube-system"},"spec":{"ports":[{"port":80,"targetPort":8443}],"selector":{"k8s-app":"kubernetes-dashboard"}}}
  creationTimestamp: 2019-04-11T09:21:23Z
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kube-system
  resourceVersion: "314064"
  selfLink: /api/v1/namespaces/kube-system/services/kubernetes-dashboard
  uid: 2cde72a3-5c3b-11e9-892c-000c2968fc47
spec:
  clusterIP: 10.101.229.15
  ports:
  - port: 443
    protocol: TCP
    targetPort: 8443
  selector:
    k8s-app: kubernetes-dashboard
  sessionAffinity: None
  # 这里指定Service的类型
  type: ClusterIP
status:
  loadBalancer: {}

所以，这种类型的Service本身是不会对集群外暴露服务的，但是却单单可以通过K8s Proxy API来访问。Proxy API是一种特殊的API，Kube-APIServer只代理这类API的HTTP请求，然后将请求转发到某个节点上的Kubelet进程监听的端口上，最后有该端口上的REST API响应请求。

在集群外部访问，需要借助于kubectl，所以集群外的节点必须配置了经过认证的kubectl，可以参看kubectl的配置章节：

$ kubectl proxy --port=8080
# 通过selfLink即可访问，注意这里的服务名需要指定https
$ curl http://localhost:8080/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
<!doctype html> <html ng-app="kubernetesDashboard"> <head> <meta charset="utf-8"> <title ng-controller="kdTitle as $ctrl" ng-bind="$ctrl.title()"></title> <link rel="icon" type="image/png" href="assets/images/kubernetes-logo.png"> <meta name="viewport" content="width=device-width"> <link rel="stylesheet" href="static/vendor.93db0a0d.css"> <link rel="stylesheet" href="static/app.ddd3b5ec.css"> </head> <body ng-controller="kdMain as $ctrl"> <!--[if lt IE 10]>
      <p class="browsehappy">You are using an <strong>outdated</strong> browser.
      Please <a href="http://browsehappy.com/">upgrade your browser</a> to improve your
      experience.</p>
    <![endif]--> <kd-login layout="column" layout-fill="" ng-if="$ctrl.isLoginState()"> </kd-login> <kd-chrome layout="column" layout-fill="" ng-if="!$ctrl.isLoginState()"> </kd-chrome> <script src="static/vendor.bd425c26.js"></script> <script src="api/appConfig.json"></script> <script src="static/app.91a96542.js"></script> </body> </html> %

这种方式要求访问节点必须具备受认证的kubectl，所以只能用做调试使用。

NodePort

NodePort是基于ClusterIP的方式来暴露服务的，不过不需要kubectl的配置，他是在每一个node上都监听同一个端口，该端口的访问都会被引导到Service的ClusterIP，后续的方式和ClusterIP的方式是一样的，例子如下：

# 以NodePort的方式在访问k8s-dashboard
$ kubectl patch svc kubernetes-dashboard -p '{"spec":{"type":"NodePort"}}' -n kube-system
# 当然如果想重新创建一个nodeport类型的svc也是OK的，这样可以自己方便的指定开放端口
$ vi nodeport-k8s-dashboard-svc.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard-nodeport
  namespace: kube-system
spec:
  ports:
  - port: 443
    protocol: TCP
    targetPort: 8443
    nodePort: 30026
  selector:
    k8s-app: kubernetes-dashboard
  sessionAffinity: None
  type: NodePort
status:
  loadBalancer: {}

$ kubectl create -f nodeport-k8s-dashboard-svc.yaml
service/kubernetes-dashboard-nodeport created

访问nodeIP:NodePort的时候出现了pod所在的node是OK的，其他的Node访问被拒绝,原因和Docker的版本有关，参看kubernets nodeport 无法访问，解决方案就是在其他的Node上修改FORWARD的链生成规则：

$ iptables -P FORWARD ACCEPT

这样就可以访问了：

$ kubectl get svc --all-namespaces -o=wide | grep kubernetes-dashboard
kube-system   kubernetes-dashboard            ClusterIP   10.96.8.148     <none>        443/TCP                  8s      k8s-app=kubernetes-dashboard
kube-system   kubernetes-dashboard-nodeport   NodePort    10.107.134.0    <none>        443:30026/TCP            4m46s   k8s-app=kubernetes-dashboard
# 集群外访问dashboard服务
$ curl https://k8s-n1:30026
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html
...

LoadBalancer

只能在Service上定义，LoadBalancer是一些特定公有云提供的负载均衡器，需要特定的云服务商提供，比如：AWS、Azure、OpenStack 和 GCE (Google Container Engine) 。这里略过不谈。

Ingress

与之前的暴露集群Service的方式都不同，Ingress其实不是一种服务。它位于多个服务之前，充当集群中的智能路由器或入口点。类似于Nginx提供的反向代理，其实官方推荐的方式就是Nginx的实现方式。这里以Nginx-Ingress的思路来构建。

Ingress的功能需要两个部分组成，一个是Nginx做网络的7层路由，一个是Ingress-controller来监听ingress rule的变化实时更新nginx的配置，所以在k8s的集群里为了实现Ingress都必须要部署一个Ingress-controller的pod，可以使用官网的套路：

# 官网推荐的yaml配置
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml
# 这个yaml里会定义一堆资源，包括role、configMap、Svc、Deployment、namespace等
# 需要注意一点，如果期望暴露的服务在不同的namespace，一定要调整这个yaml文件到对应的namespace

# 此时，pod已经正常启动了，但是svc还没有被创建（注意，不需要单独创建default-backend，都在nginx-ingress-controller的pod里了）
$ kubectl get pod -n ingress-nginx | grep ingress
nginx-ingress-controller-5694ccb578-5j7q6   1/1       Running   0          5h

# 创建一个svc来暴露nginx-ingress-controller的服务，这里使用的是NodePort
apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-controller-svc
  namespace: ingress-nginx
spec:
  ports:
  - name: http
    nodePort: 32229
    port: 80
    protocol: TCP
    targetPort: 80
  - name: https
    nodePort: 31373
    port: 443
    protocol: TCP
    targetPort: 443
  selector:
    app.kubernetes.io/name: ingress-nginx
  sessionAffinity: None
  type: NodePort

到这一步，Ingress的集群配置已经做完了，接下来进行测试，通过Ingress暴露两个内部的Nginx服务：

# 先启动两个内部的pod来承载nginx18和nginx17的服务
$ vi nginx1.7.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx1-7
  namespace: ingress-nginx
spec:
  ports:
    - port: 80
      targetPort: 80
  selector:
    app: nginx1-7
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx1-7-deployment
  namespace: ingress-nginx
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx1-7
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
        
$ vi nginx1.8.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx1-8
  namespace: ingress-nginx
spec:
  ports:
    - port: 80
      targetPort: 80
  selector:
    app: nginx1-8
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx1-8-deployment
  namespace: ingress-nginx
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx1-8
    spec:
      containers:
      - name: nginx
        image: nginx:1.8
        ports:
        - containerPort: 80
        
# 启动，注意namespace 一定和nginx-controller是一样的
$ kubectl create -f nginx1.7.yaml nginx1.8.yaml

#验证启动情况
$ kubectl get pod --all-namespaces | grep nginx
ingress-nginx   nginx1-7-deployment-6fd8995bbc-fsf9n        1/1     Running   0          5h28m
ingress-nginx   nginx1-8-deployment-854c54cb5b-hdbk4        1/1     Running   0          5h28m

$ kubectl get svc --all-namespace | grep nginx
ingress-nginx   nginx1-7                          ClusterIP      10.97.67.139     <none>         80/TCP                       5h36m
ingress-nginx   nginx1-8                          ClusterIP      10.103.212.106   <none>         80/TCP                       5h29m

然后，给这两个服务配置Ingress规则：

$ vi test-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
  namespace: ingress-nginx
spec:
  rules:
  - host: n17.my.com
    http:
      paths:
      - backend:
          serviceName: nginx1-7
          servicePort: 80
  - host: n18.my.com
    http:
      paths:
      - backend:
          serviceName: nginx1-8
          servicePort: 80

$ kubectl create -f test-ingress.yaml
$ kubectl get ing --all-namespaces | grep nginx
ingress-nginx   test                n17.my.com,n18.my.com             80      5h37m

# ingress rule 已经配置成功，测试一下
$ curl http://n17.my.com:32229
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
... ...

$ curl http://n18.my.com:32229
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
... ...
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 203,456评论 5赞 477
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 85,370评论 2赞 381
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 150,337评论 0赞 337
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,583评论 1赞 273
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,596评论 5赞 365
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,572评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,936评论 3赞 395
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,595评论 0赞 258
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,850评论 1赞 297
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2赞 321
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,371评论 4赞 318
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,951评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1赞 259
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2赞 349
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2赞 342

推荐阅读更多精彩内容