service暴露端口的方式与代理的方式

最新推荐文章于 2025-02-23 23:35:31 发布

寂寞的槟榔丶

最新推荐文章于 2025-02-23 23:35:31 发布

阅读量2.3k

点赞数

分类专栏： kubernetes 运维文章标签： kubernetes 容器服务

本文链接：https://blog.youkuaiyun.com/m0_56305656/article/details/122150427

版权

运维同时被 2 个专栏收录

43 篇文章

订阅专栏

kubernetes

6 篇文章

订阅专栏

Service 对外暴露与应用

文章目录

Service 对外暴露与应用

1 service介绍

Service可以看作是一组提供相同服务的Pod对外的访问接口。借助- Service，应用可以方便地实现服务发现和负载均衡。
service默认只支持4层负载均衡能力，没有7层功能。（可以通过Ingress实现）

2 Service的类型

ClusterIP：默认值，k8s系统给service自动分配的虚拟IP，只能在集群内部访问。
NodePort：将Service通过指定的Node上的端口暴露给外部，访问任意一个 NodeIP:nodePort都将路由到ClusterIP。
LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部的负载均衡器，并将请求转发到 :NodePort，此模式只能在云服务器上使用。
ExternalName：将服务通过 DNS CNAME 记录方式转发到指定的域名（通过 spec.externlName 设定）。

3 service暴露端口的方式

方式1：clusterIP

此类型会提供一个集群内部的虚拟IP（与pod不在同一网段），以供集群内部的pod之间通信使用。clusterIP也是kubernetes service的默认类型
主要需要以下几个组件的协同工作
apiservice：在创建service时，apiserver接收到请求以后将数据存储到etcd中。
kube-proxy：k8s的每个节点中都有该进程，负责实现service功能，这个进程负责感知service，pod的变化，并将变化的信息写入本地的iptables中
iptables:使用NAT等技术奖virtuallp的流量转至endpoint中

方式2：NodePort

NodePort模式除了使用cluster ip外，也将service的port映射到每个node的一个指定内部的port上，映射的每个node的内部port都一样。为每个节点暴露一个端口，通过nodeIP+nodeport可以访问你这个服务，同时服务依然会有cluster类型的ip+port。内部通过clusterip方式访问，外部通过nodeport方式访问

方式3：loadbalancer

loadbalancer在nodeport基础上，k8s可以请求底层云平台创建一个负载均衡器，将每个node作为后端，进行服务分发，该模式需要底层云平台（例如GCE）支持

方式4：lngress

lngress，是一种http方式的路由转发机制由lngress controller和http代理服务器组合而成，lngress controller实例监控kubernetes api，实时更新http代理服务器的转发规则。http代理服务器有GCE load-balancer、haproxy、nginx等开源方案

service是一个抽象概念，定义了一个服务的多个pod逻辑合集和访问pod的策略，一般把service称为微服务.举个例子一个a服务运行3个pod，b服务怎么访问a服务的pod，pod的ip都不是持久化的重启之后就会有变化。这时候b服务可以访问跟a服务绑定的service，service信息是固定的提前告诉b就行了，service通过Label Selector跟a服务的pod绑定,无论a的pod如何变化对b来说都是透明的.

4 service代理方式

userspace代理模式

这种模式，kube-proxy 会监视 Kubernetes master 对 Service 对象和 Endpoints 对象的添加和移除。对每一个 Service，它会在本地 Node 上打开一个端口（随机选择）。任何链接到“代理端口”的请求，都会被代理到 Service 的backend Pods 中的某个上面（如 Endpoints 所报告的同样）。使用哪一个 backend Pod，是 kube-proxy 基于 SessionAffinity 来肯定的。网络
最后，它配置 iptables 规则，捕获到达该 Service 的 clusterIP（是虚拟 IP）和 Port 的请求，并重定向到代理端口，代理端口再代理请求到 backend Pod。
默认状况下，userspace模式下的kube-proxy经过循环算法选择后端。
默认的策略是，经过 round-robin 算法来选择 backend Pod。

iptables 代理模式

这种模式，kube-proxy 会监视 Kubernetes 控制节点对 Service 对象和 Endpoints 对象的添加和移除。对每一个 Service，它会配置 iptables 规则，从而捕获到达该 Service 的 clusterIP 和端口的请求，进而将请求重定向到 Service 的一组 backend 中的某个上面。对于每一个 Endpoints 对象，它也会配置 iptables 规则，这个规则会选择一个 backend 组合。
默认的策略是，kube-proxy 在 iptables 模式下随机选择一个 backend。
使用 iptables 处理流量具备较低的系统开销，由于流量由 Linux netfilter 处理，而无需在用户空间和内核空间之间切换。这种方法也可能更可靠。
若是 kube-proxy 在 iptables模式下运行，而且所选的第一个 Pod 没有响应，则链接失败。这与userspace模式不一样：在这种状况下，kube-proxy 将检测到与第一个 Pod 的链接已失败，并会自动使用其余后端 Pod 重试。
咱们可使用 Pod readiness 探测器验证后端 Pod 是否能够正常工做，以便 iptables 模式下的 kube-proxy 仅看到测试正常的后端。这样作意味着能够避免将流量经过 kube-proxy 发送到已知已失败的Pod。

IPVS 代理模式

在 ipvs 模式下，kube-proxy监视Kubernetes服务(Service)和端点(Endpoints)，调用 netlink 接口相应地建立 IPVS 规则，并按期将 IPVS 规则与 Kubernetes服务(Service)和端点(Endpoints)同步。该控制循环可确保 IPVS 状态与所需状态匹配。访问服务(Service)时，IPVS　将流量定向到后端Pod之一。
IPVS代理模式基于相似于 iptables 模式的 netfilter 挂钩函数，可是使用哈希表做为基础数据结构，而且在内核空间中工做。这意味着，与 iptables 模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy 重定向通讯的延迟要短，而且在同步代理规则时具备更好的性能。与其余代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。
IPVS提供了更多选项来平衡后端Pod的流量。分别是：
- rr: round-robin
- lc: least connection (smallest number of open connections)
- dh: destination hashing
- sh: source hashing
- sed: shortest expected delay
- nq: never queue

注意：要在 IPVS 模式下运行 kube-proxy，必须在启动 kube-proxy 以前使 IPVS Linux 在节点上可用。当 kube-proxy 以 IPVS 代理模式启动时，它将验证 IPVS 内核模块是否可用。若是未检测到 IPVS 内核模块，则 kube-proxy 将退回到以 iptables 代理模式运行。
在这里插入图片描述

5 实例

1、创建一个deployment副本数3，然后滚动更新镜像版本，并记录这个更新记录，最后再回滚到上一个版本

[root@master mainfest]# vi 1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
  labels:
    app: test
spec:
  replicas: 3
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - image: caiaoc/httpd/v1.0
        name: test
        imagePullPolicy: IfNotPresent
      
[root@master mainfest]# kubectl apply -f 1.yaml 
deployment.apps/test1 created
[root@master mainfest]# kubectl get pod
NAME                    READY   STATUS    RESTARTS   AGE
test-9635b7736-4k75s  1/1     Running   0          1m13s
test-9635b7736-hzq27  1/1     Running   0          1m13s
test-9635b7736-p3k54  1/1     Running   0          1m13s

滚动更新

格式：kubectl set image deployment.apps/{deployment名称} {镜像名称}:={镜像名称}:{版本}

[root@master mainfest]# kubectl set image deploy/test test=caiaoc/httpd:v1.0
deployment.apps/test image updated

[root@master mainfest]# kubectl get pod		//正在升级中(蓝绿部署)
NAME                     READY   STATUS              RESTARTS   AGE
test1-7697c79b78-f9zjf   0/1     ContainerCreating   0          14s
test-9635b7736-4k75s  1/1     Running   0          4m26s
test-9635b7736-hzq27  1/1     Running   0          4m26s
test-9635b7736-p3k54  1/1     Running   0          4m26s
[root@master mainfest]# kubectl get pod		//已经升级完成
NAME                     READY   STATUS    RESTARTS   AGE
test1-7697c79b78-5rn9f   1/1     Running   0          2m12s
test1-7697c79b78-9fs4n   1/1     Running   0          67s
test1-7697c79b78-wb95c   1/1     Running   0          68s

回滚

//查看上线记录
[root@master mainfest]# kubectl rollout history deploy test	
deployment.apps/test
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

[root@master mainfest]# kubectl rollout history deploy test --revision=2
//查看某一条上线记录
deployment.apps/test with revision #2
Pod Template:
  Labels:       app=test
        pod-template-hash=84644f7fbb
  Containers:
   test1
    Image:      caiaoc/httpd:v1.0
    Port:       <none>
    Host Port:  <none>
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>
  
//回滚到上一个版本
[root@master mainfest]# kubectl rollout undo deploy	test	
deployment.apps/test1 rolled back
[root@master mainfest]# kubectl rollout history deployment test
deployment.apps/test 
REVISION  CHANGE-CAUSE
2         <none>
3         <none>

2.给一个应用扩容副本数为3

[root@master mainfest]# kubectl create deploy test2 --image nginx:latest
deployment.apps/test2 created

[root@master mainfest]# kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
test2-6947bd56f-7qq9r   1/1     Running   0          23s

[root@master mainfest]# kubectl scale deploy/test2 --replicas 3
deployment.apps/test2 scaled
[root@master mainfest]# kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
test2-fd86fb676-f9zjf   1/1      Running   0          119m
test2-fd86fb676-hzq27   1/1      Running   0          67s
test2-fd86fb676-p94c8   1/1      Running   0          67s

3、创建一个pod，其中运行着nginx、redis、memcached 3个容器

[root@master kubenetres]# cat test.yml 
apiVersion: v1
kind: Pod
metadata:
  name: test
  labels:
    app: test01
spec:
  containers:
  - image: nginx
    name: nginx
  - image: redis
    name: redis
  - image: memcached
    name: memcached
[root@master kubenetres]# kubectl apply -f test.yml 
pod/test created
[root@master kubenetres]# kubectl get pod
NAME   READY   STATUS    RESTARTS   AGE
test   3/3     Running   0          53s

4 给一个pod创建service，并可以通过ClusterIP/NodePort访问

[root@master mainfest]# vi a1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test4
  labels:
    app: test4
spec:
  containers:
  - image: nginx
    name: nginx
---
apiVersion: v1
kind: Service
metadata:
  name: test4
spec:
  ports:
  - port: 80
    targetPort: 80
    nodePort: 31960
  selector:
    app: test4
  type: NodePort

[root@master mainfest]# kubectl apply -f a1.yaml 
pod/test4 created
service/test4 created
[root@master mainfest]# kubectl get pod,svc
NAME        READY   STATUS    RESTARTS   AGE
pod/test4   1/1     Running   0          37s

NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
service/kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP        7d1h
service/test4        NodePort    10.99.153.177    <none>        80:30001/TCP   40s

[root@master mainfest]# curl 10.99.153.177
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
[root@master mainfest]# curl 192.168.200.145:31960
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>

5 创建deployment和service，使用busybox容器nslooup解析service

[root@master mainfest]# kubectl run test5 --image busybox -- sleep 6000
pod/test5 created
[root@master mainfest]# kubectl get pod
NAME    READY   STATUS    RESTARTS   AGE
test5   1/1     Running   0          17s

[root@master mainfest]# kubectl exec -it test5 -- /bin/sh
/ # nslookup kubernetes
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local
/ # 
/ # exit
[root@master test]#