K8Sサービス入力および負荷分散の暴露

外国人がサービスメソッドを公開K8S

方法外部K8Sクラスタにサービスを公開3を持っている：イングレスnodePort、ロードバランサ、および紹介するこの記事を。各メソッドは、独自の長所と短所があり、多くの場合、道の下nodePortサービスの変更は管理がより多くのハードのポートを開くためにノードにつながります。ロードバランサを使用するLBクラウド・プロバイダーのより適切な組み合わせが、場合には、それはLBのコストをより多くかかりますが過小評価されるべきではありません。イングレスは、外部被ばくのサービスのためのK8S公式の方法ですが、また、いくつかの方法が比較的多数で本番環境で、通常、クラウド環境でサービスを提供するために、LB +のIngress Ctrollerの方法です、あなたはLBの場合にできるように、ドメインnginxのリバースプロキシと少し似て適切なバックエンドサービスへのルーティングが、K8Sクラスタで、クラスタは、統一された入り口がプロキシ外部トラフィックを逆です。

サービスは、サービスの発見と負荷分散の問題を解決するが、外部からのアクセスは、NodePortタイプが外部に均衡追加の負荷を構築する必要がありますが、時にロードバランサはKubernetesは、クラウド・プロバイダーがサポートする上で実行する必要があります必要があります。イングレスは、これらの制限に対処することです。

イングレスは、トラフィックが一定のルールによって、クラスタ内のクラスタ外のサービスに到達することを可能にする一連のルールです。---リクエスト>イングレス---> -サービス。

イングレスは、3つのコンポーネントで構成されています：

1. リバースプロキシ、ロードバランサ：ソフトウェアのバランスをとる、すなわち共通の負荷、などnginxの、Haproxyとして

2 イングレスコントローラ： KubernetesはAPIと対話し、リアルタイム後端サービス、ポッドおよび他の変更を検知する、イングレスコントローラ進入組換えは、以下の構成を生成し、その後、リバースプロキシロードバランサを更新し、そのコンフィギュレーション、動的サービス発見およびアップデートリフレッシュ

3 進入：ルールのセットを、定義されましたそれは、全体的なサービスの発見とロードバランシングを実現するために、ロードバランサの設定にこのルールは入力コントローラに結合する、イングレスコントローラダイナミック書き込み、サービス名とKubernetesとの関係を対応します。

4：サービスのロードバランサ
進入する前に、サービスの制限に対処する方法を推奨サービスのロードバランサを表示されます。サービスLoad Balancerは、コンテナ内で実行し、外部の容器IPにより、レイヤ4およびレイヤ7ロードバランシングサービスを提供し、サービスおよびエンドポイントの変化を監視haproxyます。

5：カスタムバランサのロード
ロード・バランシングを行うためにカスタムコンポーネントを、代わりのKUBE-プロキシ。nginxのように加えて、好きkube2haproxy。

6：エンドポイント
サービスのいくつかの例セレクタを使用する必要はありません
外部kubernetesのクラスタ・データベースを使用してください1.。
他の名前空間またはkubernetesクラスタサービスで使用される2.service
3移行クラスタ内の後部外側kubernetesワークロード間で互いに。

1. KUBE-プロキシは、ローカルアクセスを許可します

2. NodePort物理ポートとK8S仮想マシンのIPをサービス：ポートマッピング

クラウドGCEで、いくつかの方法NodeIp + Nodeportを使用して3.ロードバランサは、AWSはロードアドレスを提供します

そのようなnginxのは、Apache、Haproxyとして雨水管外部サービスを実現するために、オープンソースリバースプロキシロードバランサを使用して前記入口

著者：MO-バイ・
リンク： https://www.jianshu.com/p/b02dd40a16da
出典：ジェーンの本が
著者によって著作権で保護されています。商業転載は非商用の転載は、ソースを明記してください、権限の作者に連絡してください。

レイヤ7ロードバランシング

負荷分散（LB）は非常に重要な意味、私たちはここの侵入の理解を容易にするために、いくつかのポイントと4と7のロードバランシングの違いを議論するために、コンテンツがたくさんあると言うことができるでマイクロサービスアーキテクチャの進化を持っています。負荷分散タイプを分割するOSIネットワーク層に応じてバランス四七いわゆる負荷（また、など、他のルールに従って分類することができる地理的な構造の適用）単純な用語で、：4つが使用されるIP負荷分散分散負荷を表します+ポートは、要求を受信し、その後、対応するサービスの後端に直接転送され、トランスポート層（トランスポート層）で動作し、次に対応するオン、仮想ホスト名、URLまたは処理後に要求を受信する7つのロードバランシングロードバランサを表しますバックエンドサービスに、アプリケーション層（アプリケーション層）で動作します。

図4は、下位層と層7つの負荷分散の差が確立されたTCP接続を示し、それは図から分かる、4つの負荷分散は、実際のTCP接続を確立する必要があり、それが直接一度だけ、クライアントとサーバの転送します接続; 7層のロード・バランシングがTCP接続を確立するために二度必要とされ、LB、LBにクライアントが決定をロードバランシングを行うために（例えば、クッキーやURLの情報など）内容に基づいて接続され、その後、セットアップメッセージLBのサーバーへ

layer4VSlayer7_LB.png

それが良いものですバランシングのレイヤ7ロード？

？/パケット処理、4層LBのCPUより集中的な、しかし非常に小さなパフォーマンスの低下が展開するので、
あなたには、クッキー情報、こうしたURLに基づいて、よりインテリジェントな負荷分散戦略を、書き、さらにいくつかの最適化と、暗号化、圧縮などの修正を、実行するコンテンツを受信することができます。
パフォーマンスを向上させるために低速なサーバー接続の問題を軽減するために、バッファの方法を使用します
デバイスは、7層のロードバランシングがしばしばリバースプロキシサーバと呼ばれている（逆？プロキシサーバー）

リバースプロキシ

举个例子：
正向代理：在使用VPS访问的时候，通常会使用一个本地的代理服务器，浏览器的网络包会先经过本地的代理服务器，代理服务器会通过远在异国它乡的电脑来访问并返回消息；这就好比去附近的咖啡店要先问一下手机咖啡店在哪里一样，手机就是一个正向代理服务器。
反向代理：当访问的请求到达时，那边也设置了一个代理服务器，它通过查看请求的URL，发现是想查找视频内容，于时把消息转给了视频搜索服务器（过程是我乱说的），这就好比你去朋友家做客，开门的却是个管家，问你找谁？这时候管家就是一个反向代理了。

其他OSI层也可以做反向代理

ingress

k8s 对外暴露服务（service）主要有两种方式：NotePort, LoadBalance，此外externalIPs也可以使各类service对外提供服务，但是当集群服务很多的时候，NodePort方式最大的缺点是会占用很多集群机器的端口；LB方式最大的缺点则是每个service一个LB又有点浪费和麻烦，并且需要k8s之外的支持；而ingress则只需要一个NodePort或者一个LB就可以满足所有service对外服务的需求。工作机制大致可以用下图表示：

实际上，ingress相当于一个7层的负载均衡器，是k8s对反向代理的一个抽象。大概的工作原理也确实类似于Nginx，可以理解成在 Ingress 里建立一个个映射规则 , ingress Controller 通过监听 Ingress这个api对象里的配置规则并转化成 Nginx 的配置（kubernetes声明式API和控制循环） , 然后对外部提供服务。ingress包括：ingress controller和ingress resources

ingress controller：核心是一个deployment，实现方式有很多，比如nginx, Contour, Haproxy, trafik, Istio，需要编写的yaml有：Deployment, Service, ConfigMap, ServiceAccount（Auth），其中service的类型可以是NodePort或者LoadBalancer。

ingress resources：这个就是一个类型为Ingress的k8s api对象了，这部分则是面向开发人员。

使用 Ingress 对外暴露服务

为了快速体验 Ingress，下面部署一个 nginx 服务，然后通过 Ingress 对外暴露 nginx service 进行访问。
首先部署 nginx 服务：
Deployment + Service：nginx.yml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 2
template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
name: nginx
spec:
selector:
    app: nginx
ports:
    - port: 80
      targetPort: 80

kubectl create -f nginx.yml

接下来创建 Ingress 对外暴露 nginx service 80 端口：
ingress.yml:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-nginx
annotations:
    # use the shared ingress-nginx
    kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: nginx.kube.com
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx
          servicePort: 80

说明：
    kubernetes.io/ingress.class: "nginx"：Nginx Ingress Controller 根据该注解自动发现 Ingress；
    host: nginx.kube.com：对外访问的域名；
    serviceName: nginx：对外暴露的 Service 名称；
    servicePort: 80：nginx service 监听的端口；

注意：创建的 Ingress 必须要和对外暴露的 Service 在同一命名空间下！
将域名 nginx.kube.com 绑定到 k8s 任意节点 ip 即可访问：http://nginx.kube.com
上面的示例不支持 https 访问，下面举一个支持 https 的 Ingress 例子：通过 Ingress 访问 kubernetes dashboard 服务。
通过 Ingress 访问 kubernetes dashboard（支持 HTTPS 访问）
之前我们使用 helm 以 nodePort 的方式部署了 kubernetes dashboard：「helm 部署 kubernetes-dashboard」，从集群外部只能通过 nodeIP:nodePort 端口号访问，接下来基于之前部署的 kubernetes-dashboard 配置如何通过 Ingress 访问，并且支持 HTTPS 访问，HTTP 自动跳转到 HTTPS。：
首先，练习使用，先用自签名证书来代替吧：

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout kube-dashboard.key -out kube-dashboard.crt -subj "/CN=dashboard.kube.com/O=dashboard.kube.com"

使用生成的证书创建 k8s Secret 资源，下一步创建的 Ingress 会引用这个 Secret：
kubectl create secret tls kube-dasboard-ssl --key kube-dashboard.key --cert kube-dashboard.crt -n kube-system
创建 Ingress 资源对象（支持 HTTPS 访问）：
kube-dashboard-ingress.yml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-kube-dashboard
annotations:
    # use the shared ingress-nginx
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
tls:
- hosts:
    - dashboard.kube.com
    secretName: kube-dasboard-ssl
rules:
- host: dashboard.kube.com
    http:
      paths:
      - path: /
        backend:
          serviceName: kubernetes-dashboard
          servicePort: 443
kubectl create -f kube-dashboard-ingress.yml -n kube-system

说明：
    kubernetes.io/ingress.class: "nginx"：Inginx Ingress Controller 根据该注解自动发现 Ingress；
    nginx.ingress.kubernetes.io/backend-protocol: Controller 向后端 Service 转发时使用 HTTPS 协议，这个注解必须添加，否则访问会报错，可以看到 Ingress Controller 报错日志：kubectl logs -f nginx-ingress-controller-mg8df

    2019/08/12 06:40:00 [error] 557#557: *56049 upstream sent no valid HTTP/1.0 header while reading response header from upstream, client: 192.168.26.10, server: dashboard.kube.com, request: “GET / HTTP/1.1”, upstream: “http://10.244.1.8:8443/”, host: “dashboard.kube.com”

报错原因主要是 dashboard 服务后端只支持 https，但是 Ingress Controller 接到客户端的请求时往后端 dashboard 服务转发时使用的是 http 协议，解决办法就是给创建的 Ingress 设置：nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" 注解。解决方法参考自 StackOverflow：https://stackoverflow.com/questions/48324760/ingress-configuration-for-dashboard

    secretName: kube-dasboard-ssl：https 证书 Secret；
    host: dashboard.kube.com：对外访问的域名；
    serviceName: kubernetes-dashboard：集群对外暴露的 Service 名称；
    servicePort: 443：service 监听的端口；

    注意：创建的 Ingress 必须要和对外暴露的 Service 在同一命名空间下！
将域名 dashboard.kube.com 绑定到 k8s 任意节点 ip 即可访问：https://dashboard.kube.com

7层负载均衡

负载均衡（LB）在微服务架构演进中具有非常重要的意义，可以说的内容有很多，这里仅仅讨论四层和七层负载均衡的一些要点和区别，以便于对ingress的理解。所谓四层和七层负载均衡是按照网络层次OSI来划分的负载均衡类型（也可以按照其他的规则来分类，比如：应用的地理结构），简单来说：四层负载均衡表示负载均衡器用ip+port接收请求，再直接转发到后端对应的服务上，工作在传输层( transport layer )；七层负载均衡表示负载均衡器根据虚拟的url或主机名来接收请求，经过处理后再转向相应的后端服务上，工作在应用层( application layer )。

下图表示了4层和7层负载均衡在建立TCP连接上的区别，从图中可以看出，四层负载均衡需要建立的TCP连接其实之有一个，它只做一次转发，client直接和server连接；而7层负载均衡则需要建立两次TCP连接，client到LB，LB根据消息中的内容( 比如URL或者cookie中的信息 )来做出负载均衡的决定，接着建立LB到server的连接。

layer4VSlayer7_LB.png

7层负载均衡有什么好处呢？

因为存在解包/封包的过程，比4层LB更加CPU‑intensive，但是却极少降低性能；
可以编写更加智能的负载均衡策略，比如根据URL、cookie中的信息等，甚至对接收到的内容做一些优化和修改，比如加密、压缩；
使用buffer的方式来缓解服务器连接慢的问题，从而提高性能
具有7层负载均衡功能的设备通常也被称为反向代理服务器（reverse‑proxy server）

反向代理

举个例子：
正向代理：在使用VPS访问 $Google$ 的时候，通常会使用一个本地的代理服务器，浏览器的网络包会先经过本地的代理服务器，代理服务器会通过远在异国它乡的电脑来访问 $Google$ 并返回消息；这就好比去附近的咖啡店要先问一下手机咖啡店在哪里一样，手机就是一个正向代理服务器。
反向代理：当访问的请求到达 $Google$ 时， $Google$ 那边也设置了一个代理服务器，它通过查看请求的URL，发现是想查找视频内容，于时把消息转给了视频搜索服务器（过程是我乱说的），这就好比你去朋友家做客，开门的却是个管家，问你找谁？这时候管家就是一个反向代理了。
关于反向代理的好处这里就不多介绍，感兴趣可以看这里

其他OSI层也可以做反向代理

ingress

k8s 对外暴露服务（service）主要有两种方式：NotePort, LoadBalance，此外externalIPs也可以使各类service对外提供服务，但是当集群服务很多的时候，NodePort方式最大的缺点是会占用很多集群机器的端口；LB方式最大的缺点则是每个service一个LB又有点浪费和麻烦，并且需要k8s之外的支持；而ingress则只需要一个NodePort或者一个LB就可以满足所有service对外服务的需求。工作机制大致可以用下图表示：

ingress.png

实际上，ingress相当于一个7层的负载均衡器，是k8s对反向代理的一个抽象。大概的工作原理也确实类似于Nginx，可以理解成在 Ingress 里建立一个个映射规则 , ingress Controller 通过监听 Ingress这个api对象里的配置规则并转化成 Nginx 的配置（kubernetes声明式API和控制循环） , 然后对外部提供服务。ingress包括：ingress controller和ingress resources

ingress controller：核心是一个deployment，实现方式有很多，比如nginx, Contour, Haproxy, trafik, Istio，需要编写的yaml有：Deployment, Service, ConfigMap, ServiceAccount（Auth），其中service的类型可以是NodePort或者LoadBalancer。

ingress resources：这个就是一个类型为Ingress的k8s api对象了，这部分则是面向开发人员。

假设已经有两个服务部署在了k8s集群内部：

$ kubectl get svc,deploy
NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
svc/coffee-svc   ClusterIP   <none>       <none>        80/TCP    1m
svc/tea-svc      ClusterIP   <none>       <none>        80/TCP    1m

NAME            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deploy/coffee   2         2         2            2           1m
deploy/tea      1         1         1            1           1m

作者：MunCN
链接：https://www.jianshu.com/p/97dd4d59ac5a
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

对外服务方式

1. kube-proxy 只允许本地访问

2. NodePort 使用物理机端口和k8s service虚拟ip:端口映射

3. LoadBalancer 使用NodeIp+Nodeport的方式实现，配合云环境GCE、aws提供的负载地址