文章目录

undefined

怎么跟你说 Service的出现，就是解决ip不固定的问题，怎么解决呢？听小刘慢慢道来

当Pod宕机后重新生成时，其IP等状态信息可能会变动，Service会根据Pod的Label对这些状态信息进行监控和变更，保证上游服务不受Pod的变动而影响。

一、Service 简介

1.1 Service 概念

Kubernetes Service定义了这样一种抽象： Service是一种可以访问 Pod逻辑分组的策略， Service通常是通过 Label Selector访问 Pod组。

Service能够提供负载均衡的能力，但是在使用上有以下限制：只提供 4 层负载均衡能力，而没有 7 层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上 4 层负载均衡是不支持的

s 1.2 Service 类型

Service在 K8s中有以下四种类型：

① ClusterIp

默认类型，自动分配一个仅 Cluster内部可以访问的虚拟 IP

② NodePort

在 ClusterIP基础上为 Service在每台机器上绑定一个端口，这样就可以通过 : NodePort来访问该服务。

③ LoadBalancer

在 NodePort的基础上，借助 Cloud Provider创建一个外部负载均衡器，并将请求转发到 NodePort

④ ExternalName

把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 Kubernetes 1.7或更高版本的 kube-dns才支持。

1.3 Service 基础导论

客户端访问节点时通过 iptables实现的
iptables规则是通过 kube-proxy写入的
apiserver通过监控 kube-proxy去进行对服务和端点的监控
kube-proxy通过 pod的标签（ lables）去判断这个断点信息是否写入到 Endpoints里

二、代理

2.1 VIP 和 Service 代理

在 Kubernetes集群中，每个 Node运行一个 kube-proxy进程。 kube-proxy负责为 Service实现了一种 VIP（虚拟 IP）的形式，而不是 ExternalName的形式。在 Kubernetes v1.0版本，代理完全在 userspace。在 Kubernetes v1.1版本，新增了 iptables代理，但并不是默认的运行模式。从 Kubernetes v1.2起，默认就是 iptables代理。在 Kubernetes v1.8.0-beta.0中，添加了 ipvs代理。

在 Kubernetes 1.14版本开始默认使用 ipvs代理。

在 Kubernetes v1.0版本， Service是 4 层（ TCP/ UDP over IP）概念。在 Kubernetes v1.1版本，新增了 Ingress API（ beta版），用来表示 7 层（ HTTP）服务

为何不使用 round-robin DNS？

DNS会在很多的客户端里进行缓存，很多服务在访问 DNS进行域名解析完成、得到地址后不会对 DNS的解析进行清除缓存的操作，所以一旦有他的地址信息后，不管访问几次还是原来的地址信息，导致负载均衡无效

2.2 代理模式分类

① userspace 代理模式

② iptables 代理模式

③ ipvs 代理模式

ipvs代理模式中 kube-proxy会监视 Kubernetes Service对象和 Endpoints，调用 netlink接口以相应地创建 ipvs规则并定期与 Kubernetes Service对象和 Endpoints对象同步 ipvs规则，以确保 ipvs状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod。

与 iptables类似， ipvs于 netfilter的 hook功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着 ipvs可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外， ipvs为负载均衡算法提供了更多选项，例如：

rr：轮询调度
lc：最小连接数
dh：目标哈希
sh：源哈希
sed：最短期望延迟
nq：不排队调度

三、Service 使用

3.1 ClusterIp

ClusterIP主要在每个 node节点使用 iptables，将发向 ClusterIP对应端口的数据，转发到 kube-proxy中。然后 kube-proxy自己内部实现有负载均衡的方法，并可以查询到这个 service下对应 pod的地址和端口，进而把数据转发给对应的 pod的地址和端口。

为了实现图上的功能，主要需要以下几个组件的协同工作：

apiserver：用户通过 kubectl命令向 apiserver发送创建 service的命令， apiserver接收到请求后将数据存储到 etcd中
kube-proxy： Kubernetes的每个节点中都有一个叫做 kube-porxy的进程，这个进程负责感知 service、 pod的变化，并将变化的信息写入本地的 iptables规则中
iptables：使用 NAT等技术将 virtualIP的流量转至 endpoint中

创建 myapp-deploy.yaml文件

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      release: stabel
  template:
    metadata:
      labels:
        app: myapp
        release: stabel
        env: test
    spec:
      containers:
      - name: myapp
        image: wangyanglinux/myapp:v2
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80

创建 Service信息：

apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  type: ClusterIP
  selector:
    app: myapp
    release: stabel
  ports:
  - name: http
    port: 80
    targetPort: 80

执行命令：


[root@master service]
deployment.apps/myapp-deploy created
[root@master service]
NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE      NOMINATED NODE   READINESS GATES
myapp-deploy-6cc7c66999-5n2dj   1/1     Running   0          16s     10.244.1.26   worker1   <none>           <none>
myapp-deploy-6cc7c66999-dfgqb   1/1     Running   0          16s     10.244.1.27   worker1   <none>           <none>
myapp-deploy-6cc7c66999-wz6zk   1/1     Running   0          16s     10.244.2.30   worker2   <none>           <none>

[root@master service]
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>

[root@master service]
service/myapp created
[root@master service]
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
myapp        ClusterIP   10.104.96.7      <none>        80/TCP    8s

[root@master service]
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.104.96.7:80 rr
  -> 10.244.1.26:80               Masq    1      0          0
  -> 10.244.1.27:80               Masq    1      0          1
  -> 10.244.2.30:80               Masq    1      0          1

[root@master service]
myapp-deploy-6cc7c66999-5n2dj
[root@master service]
myapp-deploy-6cc7c66999-wz6zk
[root@master service]
myapp-deploy-6cc7c66999-dfgqb
[root@master service]
myapp-deploy-6cc7c66999-5n2dj

3.2 Handless Service

有时不需要或不想要负载均衡，以及单独的 Service IP。遇到这种情况，可以通过指定 spec.clusterIP的值为 None来创建 Headless Service 。这类 Service并不会分配 Cluster IP， kube-proxy不会处理它们，而且平台也不会为它们进行负载均衡和路由。

[root@master service]

apiVersion: v1
kind: Service
metadata:
  name: myapp-headless
  namespace: default
spec:
  selector:
    app: myapp
  clusterIP: "None"
  ports:
  - port: 80
	targetPort: 80

[root@master service]

3.3 NodePort

NodePort的原理在于在 Node上开了一个端口，将向该端口的流量导入到 kube-proxy，然后由 kube-proxy进一步到给对应的 pod。

创建 Service信息：

apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  type: NodePort
  selector:
    app: myapp
    release: stabel
  ports:
  - name: http
    port: 80
    targetPort: 80

执行命令：


[root@master service]
service/myapp configured
[root@master service]
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
myapp        NodePort    10.104.96.7      <none>        80:30333/TCP   46m

[root@master service]
tcp6       0      0 :::30333                :::*                    LISTEN      3459/kube-proxy

C:\Users\MrHu>curl 192.168.182.100:30333/hostname.html
myapp-deploy-6cc7c66999-5n2dj

3.4 LoadBalancer

LoadBalancer和 NodePort其实是同一种方式。区别在于 LoadBalancer比 NodePort多了一步，就是可以调用 Cloud provider去创建 LB来向节点导流。

3.5 ExternalName

这种类型的 Service通过返回 CNAME和它的值，可以将服务映射到 externalName字段的内容( 例： hub.hc.com )。 ExternalName Service是 Service的特例，它没有 selector，也没有定义任何的端口和 Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务。

kind: Service
apiVersion: v1
metadata:
  name: my-service-1
  namespace: default
spec:
  type: ExternalName
  externalName: hub.hc.com

当查询主机 my-service.defalut.svc.cluster.local时，集群的 DNS服务将返回一个值 hub.hc.com的 CNAME记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在 DNS层，而且不会进行代理或转发。

四、Ingress

4.1 Ingress 简介

Service只支持4层负载均衡，而Ingress有7层功能

Nginx可以通过虚拟主机域名区分不同的服务，而每个服务通过 upstream进行定义不同的负载均衡池，再加上 location进行负载均衡的反向代理，在日常使用中只需要修改 nginx.conf即可实现，但是在 K8S中又该如何实现这种方式调度呢？

K8S引入了 ingress自动进行服务的调度， ingress包含两大组件： ingress controller和 ingress。

ingress：修改 Nginx配置操作被抽象成了 ingress对象，
ingress controller： ingress controller通过与 kubernetes API交互，动态的去感知进集群中 Ingress规则变化，然后读取它，然后读取它，按照它自己的模板生成一段 nginx配置，再写到 nginx Pod中，最后 reload以下，工作流程如下图：

Ingress 的安装

① 下载 Ingress镜像：

[root@master ingress]
REPOSITORY                                                       TAG                 IMAGE ID            CREATED             SIZE

quay.io/kubernetes-ingress-controller/nginx-ingress-controller   0.25.0              02149b6f439f        13 months ago       508MB

② 拷贝配置文件 mandatory.yaml、 service-nodeport.yaml，位置参考 https://github.com/kubernetes/ingress-nginx/tree/nginx-0.25.0/deploy/static。

③ 部署 ingress-controller对外提供服务：


[root@master ingress]

[root@master ingress]
NAME                                        READY   STATUS    RESTARTS   AGE
nginx-ingress-controller-7995bd9c47-kldqr   1/1     Running   0          13h

④ 给 ingress-controller建立一个 servcie，接收集群外部流量


[root@master ingress]

[root@master ingress]
NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx   NodePort   10.106.6.160   <none>        80:31347/TCP,443:32445/TCP   13h

4.2 Ingress HTTP 代理访问

创建 deployment和 svc

[root@master ingress]
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-dm
spec:
  replicas: 2
  template:
    metadata:
      labels:
        name: nginx
    spec:
      containers:
        - name: nginx
          image: wangyanglinux/myapp:v1
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    name: nginx

[root@master ingress]

[root@master ingress]
NAME                        READY   STATUS    RESTARTS   AGE
nginx-dm-7d967c7ff5-kvz6f   1/1     Running   0          5m20s
nginx-dm-7d967c7ff5-wk4jv   1/1     Running   0          5m21s

[root@master ingress]
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
nginx-svc    ClusterIP   10.100.57.201   <none>        80/TCP    16m

创建 ingress:

[root@master ingress]
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-test
spec:
  rules:
    - host: www1.hc.com
      http:
        paths:
        - path: /
          backend:
            serviceName: nginx-svc
            servicePort: 80

[root@master ingress]

[root@master ingress]
NAME         HOSTS         ADDRESS   PORTS   AGE
nginx-test   www1.hc.com             80      23s

[root@master ingress]
NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx   NodePort   10.106.6.160   <none>        80:31347/TCP,443:32445/TCP   13h

在 Window系统中配置 hosts后进行访问：

C:\Users\MrHu>curl www1.hc.com:31347/hostname.html
nginx-dm-7d967c7ff5-wk4jv

4.3 Ingress HTTPS 代理访问

创建证书，以及 cert存储方式：

[root@master cert]

[root@master cert]
secret/tls-secret created

[root@master cert]
NAME                  TYPE                                  DATA   AGE
default-token-cjdrb   kubernetes.io/service-account-token   3      6d14h
tls-secret            kubernetes.io/tls

创建 deployment和 svc:

[root@master ingress]
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-https
spec:
  replicas: 2
  template:
    metadata:
      labels:
        name: nginx2
    spec:
      containers:
        - name: nginx
          image: wangyanglinux/myapp:v2
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc-2
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    name: nginx2

[root@master ingress]

创建 ingress：

[root@master ingress]
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-https
spec:
  tls:
    - hosts:
      - www2.hc.com
      secretName: tls-secret
  rules:
    - host: www2.hc.com
      http:
        paths:
        - path: /
          backend:
            serviceName: nginx-svc-2
            servicePort: 80

[root@master ingress]

[root@master ingress]
NAME          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
nginx-svc-2   ClusterIP   10.106.108.145   <none>        80/TCP    10m

[root@master ingress]
NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx   NodePort   10.106.6.160   <none>        80:31347/TCP,443:32445/TCP   14h

在 Window系统中配置 hosts后进行访问：

4.4 进行 BasicAuth

[root@master ingress]

[root@master ingress]

[root@master ingress]

[root@master ingress]
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-with-auth
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: basic-auth
    nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required - foo'
spec:
  rules:
  - host: auth.hc.com
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-svc-2
          servicePort: 80

[root@master ingress]

[root@master ingress]
NAME                HOSTS         ADDRESS   PORTS     AGE
ingress-with-auth   auth.hc.com             80        15s
nginx-https         www2.hc.com             80, 443   23m

在 Window系统中配置 hosts后进行访问：

4.5 Nginx进行重写

Nginx重写字段：

创建 ingress：

[root@master ingress]
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-re
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: http://www1.hc.com:31347/hostname.html
spec:
  rules:
  - host: re.hc.com
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-svc
          servicePort: 80

[root@master ingress]

在 Window系统中配置 hosts后进行访问 re.hc.com:31347：

微信搜一搜 : 全栈小刘，获取文章 pdf 版本

JAVA学习网

分类

7. 丈母娘嫌我不懂K8s的Service概念，让我去面壁

文章目录

一、Service 简介

1.1 Service 概念

s 1.2 Service 类型

1.3 Service 基础导论

二、代理

2.1 VIP 和 Service 代理

2.2 代理模式分类

三、Service 使用

3.1 ClusterIp

3.2 Handless Service

3.3 NodePort

3.4 LoadBalancer

3.5 ExternalName

四、Ingress

4.1 Ingress 简介

4.2 Ingress HTTP 代理访问

4.3 Ingress HTTPS 代理访问

4.4 进行 BasicAuth

4.5 Nginx进行重写