网站收录量,网站建设哪儿好,网站字体只能用,哈尔滨市建设厅网站hostNetwork、 hostPort、 NodePort、 LoadBalancer、 Ingress 暴露Pod与Service一样#xff0c;因为Pod就是Service的backend
1、hostNetwork#xff1a;true 这是一种直接定义 Pod 网络的方式。 如果在 Pod 中使用 hostNetwork:true 配置#xff0c; pod 中运行的应用程序… hostNetwork、 hostPort、 NodePort、 LoadBalancer、 Ingress 暴露Pod与Service一样因为Pod就是Service的backend
1、hostNetworktrue 这是一种直接定义 Pod 网络的方式。 如果在 Pod 中使用 hostNetwork:true 配置 pod 中运行的应用程序可以直接看到 pod 启动的主机的网络接口。 在主机的所有网络接口上都可以访问到该应用程序。注每次pod的IP是会变化的 使用主机网络的 pod 的示例定义
apiVersion: v1
kind: Pod
metadata:name: influxdb
spec:hostNetwork: truecontainers:- name: influxdbimage: influxdb
部署该 Pod
$ kubectl create -f influxdb-hostnetwork.yml
访问该 pod 所在主机的 8086 端口
curl -v http://$POD_IP:8086/ping
将看到 204 No Content 的 204 返回码说明可以正常访问。 注意: 1. 每次启动这个 Pod 的时候都可能被调度到不同的节点上所有外部访问 Pod 的 IP 也是变化的而且调度 Pod 的时候还需要考虑是否与宿主机上的端口冲突因此一般情况下除非您知道需要某个特定应用占用特定宿主机上的特定端口时才使用 hostNetwork: true 的方式。 2. 这种 Pod 的网络模式有一个用处就是可以将网络插件包装在 Pod 中然后部署在每个宿主机上这样该 Pod 就可以控制该宿主机上的所有网络。 2、hostPort 这是一种直接定义 Pod 网络的方式。 hostPort 直接将容器的端口与所调度的节点上的端口路由绑定这样用户就可以通过宿主机的 IP 加上来访问 Pod 了。 如
apiVersion: v1
kind: Pod
metadata:name: influxdb
spec:containers:- name: influxdbimage: influxdbports:- containerPort: 8086hostPort: 8086 注这样做有个缺点因为 Pod 重新调度的时候该 Pod 被调度到的宿主机可能会变动这样就变化了用户必须自己维护一个 Pod 与所在宿主机的对应关系。 这种网络方式可以用来做 nginx Ingress controller 。外部流量都需要通过 kubenretes node 节点的 80 和 443 端口。 3、NodePort 1. 是K8s里一个广泛应用的服务暴露方式。 2. K8s中的service默认情况都是使用Cluster IP这种类型会产生一个只能在内部访问的Cluster IP3.如果想能够直接访问service需要将service type修改为nodePort。 4.同时给service指定一个nodeport值(30000-32767)用 --service-node-port-range定义。 集群外就可以使用K8s任意一个节点的IP加上30000端口访问该服务了kube-proxy会自动将流量以轮询的方式转发给该service的每一个pod。 apiVersion: v1
kind: Pod
metadata:name: influxdblabels:name: influxdb
spec:containers:- name: influxdbimage: influxdbports:- containerPort: 8086
同时还可以给 service 指定一个 nodePort 值范围是 30000-32767这个值在 API server 的配置文件中用 --service-node-port-range 定义。
kind: Service
apiVersion: v1
metadata:name: influxdb
spec:type: NodePortports:- port: 8086nodePort: 30000selector:name: influxdb 1. 集群外就可以使用 kubernetes 任意一个节点的 IP 加上 30000 端口访问该服务了。kube-proxy 会自动将流量以 round-robin 的方式转发给该 service 的每一个 pod。 2. 这种服务暴露方式无法让你指定自己想要的应用常用端口不过可以在集群上再部署一个反向代理作为流量入口。 4、LoadBalancer
LoadBalancer 只能在 service 上定义。这是公有云提供的负载均衡器如 AWS、Azure、CloudStack、GCE 等。
kind: Service
apiVersion: v1
metadata:name: influxdb
spec:type: LoadBalancerports:- port: 8086selector:name: influxdb
查看服务
kubectl get svc influxdb 内部可以使用ClusterIP:Port来访问服务
外部可以使用两种方式 任意节点的IP加30051端口访问服务 10.97.121.42:30051使用EXTERNAL-IP来访问这是云供应商提供的负载均衡IP 10.13.242.236:8086
5、Ingress
Ingress 是自 kubernetes1.1 版本后引入的资源类型。必须要部署 Ingress controller 才能创建 Ingress 资源Ingress controller 是以一种插件的形式提供。
Ingress controller 部署在 Kubernetes 之上的 Docker 容器。它的 Docker 镜像包含一个像 nginx 或 HAProxy 的负载均衡器和一个控制器守护进程。控制器守护程序从 Kubernetes 接收所需的 Ingress 配置。它会生成一个 nginx 或 HAProxy 配置文件并重新启动负载平衡器进程以使更改生效。换句话说Ingress controller 是由 Kubernetes 管理的负载均衡器。
Kubernetes Ingress 提供了负载平衡器的典型特性HTTP 路由粘性会话SSL 终止SSL 直通TCP 和 UDP 负载平衡等。目前并不是所有的 Ingress controller 都实现了这些功能需要查看具体的 Ingress controller 文档。
ingress controller是由K8s管理的负载均衡容器它的镜像包含一个nginx或HAProxy负载均衡器和一个控制器守护进程。
apiVersion: extensions/v1beta1
kind: Ingress
metadata:name: influxdb
spec:rules:- host: influxdb.kube.example.comhttp:paths:- backend:serviceName: influxdbservicePort: 8086
外部访问URL http://influxdb.kube.example.com/ping 访问该服务入口是80端口然后Ingress controller直接将流量转发给后端Pod不需再经过kube-proxy的转发比LoadBalance方式更高效。
