不同点 使用 hostNetwork,pod 实际上用的是 pod 宿主机的网络地址空间:即 pod IP 是宿主机 IP,而非 cni 分配的 pod IP,端口是宿主机网络监听接口。 当 pod 同时使用了 hostNetwork 和 hostPort,那么 hostNetwork 将会直接使用宿主机网络命名空间,hostPort 其实就形同虚设了。 可以认为 hostNetwork 选项优先级要高于 hostPort。 hostNetwork示例 apiVersion: apps/v1 kind: Deployment metadata: name: nginx-hostnetwork namespace: cjweichen : 25% type: RollingUpdate template: metadata: labels: k8s-app: nginx-hostnetwork
ingress通过daemonSet,nodeSelector,hostNetwork方式部署 ? ingress-nginx terminationGracePeriodSeconds: 300 nodeSelector: isIngress: "true" hostNetwork
这种设计为微服务架构提供了理想的沙箱环境,但在某些特殊场景下,我们需要让 Pod 直接"拥抱"宿主机网络——这就是 hostNetwork: true 的用武之地。 1、解剖 hostNetwork 原理与特性 1.1 核心机制 # 查看普通 Pod 的网络命名空间 kubectl exec -it <pod-name> -- ip addr # 查看 hostNetwork Pod 的网络命名空间(等同于宿主机) kubectl exec -it <hostnetwork-pod> -- ip addr 当设置 hostNetwork: true 时: 网络栈共享:Pod hostNetwork 模型:直接使用宿主机网络,跳过 Kubernetes 的网络虚拟化层,性能更高,但失去网络隔离性。 在您下一次考虑使用 hostNetwork 时,不妨先问三个问题: 是否真的需要突破网络隔离? 是否有更安全的替代方案? 是否已做好全链路监控和防护?
设置Pod级别的hostNetwork=true。 该Pod中所有容器的端口号都将直接被映射到物理机上。 在此,直接编写pod-hostnetwork-rc.yaml,验证同一台宿主机上能否创建多个该pod。 apiVersion: v1 kind: ReplicationController metadata: name: hostnetwork labels: app: hostnetwork app: hostnetwork spec: hostNetwork: true containers: - name: hostnetwork apiVersion: v1 kind: Service metadata: name: hostnetwork labels: app: hostnetwork spec: type
四、什么是hostnetwork 在hostnetwork模式下,pod的IP和端口会直接绑定到宿主机的IP和端口。 上面的配置文件中,打开了hostnetwork模式.。pod部署以后,pod的IP直接就是宿主机的IP。 例如,在Openshift中,router就是hostnetwork模式。 hostnetwork相比于nodeport,好处在于转发路径短。缺点是占用node的实际端口,无法在用一个节点同时运行相同端口的两个pod。同时,hostnetwork无法跨node。 所以说,router就是一个以hostnetwork方式运行在node上的容器化haproxy,它占用了node的80、443、1936端口。 整体而言,hostnetwork的方式转发路径短,性能比nodeport好。
downwardAPI,emptyDir,persistentVolumeClaim,secret,projected 其次,创建一个提升策略,用于那些需要提升权限的Pod,比如kube-proxy,它就需要hostNetwork nginx-55fc968d9-qn2vr 1/1 Running 0 17m 但是如果我们现在给这个Deployment清单加一个hostNetwork containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent hostNetwork 5cd65fd4c6-" is forbidden: unable to validate against any pod security policy: [spec.securityContext.hostNetwork : Invalid value: true: Host network is not allowed to be used] 提示我们hostNetwork不允许被使用。
例如:Admission controller会验证请求者是否拥有使用hostNetwork等kubernetes资源的权限。 Policy 对授权资源使用权限的规则定义在YAML文件中。 Breaking Policy Rules 在这部分,我将在deployment中使用已经在restrictive policy中禁止的“hostNetwork”。 -" is forbidden: unable to validate against any pod security policy: [spec.securityContext.hostNetwork apiVersion: apps/v1 kind: Deployment metadata: name: nginx-hostnetwork-deployment namespace: kube-system 注意:由于已经对kube-system命名空间的user和service account授权使用hostNetwork,可见nginx-hostnetwork-deployment pod已经部署在kube-system
解决方案二 服务 A 的 Pod 配置hostNetwork: true。 服务 A 内部还有其他进程,监听了端口,容易和节点的其他进程冲突。同时还会暴漏服务 A 内部的其他服务。 解决方案三 新增一个 nginx Pod,并配置hostNetwork: true,dnsPolicy: ClusterFirstWithHostNet,通过七层代理来转发流量到服务 A 的 service 解决方案四 新增一个 nginx Pod,并配置hostNetwork: true,dnsPolicy: ClusterFirstWithHostNet,通过四层代理来转发流量到服务 A 的 service 解决方案五 新增一个 ubuntu Pod,并配置hostNetwork: true,通过 iptables 来转发流量。
2. hostNetwork:true 当Pod配置为时hostNetwork: true,在此Pod中运行的应用程序可以直接看到启动Pod的主机的网络接口。 这是使用主机网络的Pod的示例定义: apiVersion: v1 kind: Pod metadata: name: nginx spec: hostNetwork: true containers : - name: nginx image: nginx hostNetwork的优点是直接使用宿主机的网络,只要宿主机能访问,Pod就可以访问; 缺点: 易用性:Pod漂移到其他node : nginx image: nginx ports: - containerPort: 80 hostPort: 80 hostport和hostnetwork 类似,不过它是经过了一系列的iptables规则所做的fullnat,并且性能来说是不如hostnetwork的,多了iptables的转发。
PSP 基本覆盖了 SecurityContext 的各项能力,除此之外还加入了一些特技: hostPID、hostIPC hostNetwork、hostPorts allowedHostPaths 在没有启用 PSP 的情况下,可以用如下策略完成这个限制: apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: check-hostnetwork spec: validationFailureAction: enforce background: false rules: - name: check-hostnetwork match: resources: kinds: - Deployment validate: message: "Hostnetwork is not allowed" pattern: spec: template: spec: =(hostNetwork
HostNetwork 为了暴露 Ingress Gateway,可以使用 HostNetwork 模式运行,上篇文章的方法是直接修改 Deployment,但这种方法还是不太优雅。 istio-ingressgateway patches: - path: spec.template.spec value: hostNetwork istio-ingressgateway patches: - path: spec.template.spec value: hostNetwork
本文转载自jimmysong的博客,可点击文末阅读原文查看 本文主要讲解访问kubernetes中的Pod和Serivce的几种方式,包括如下几种: hostNetwork hostPort NodePort LoadBalancer Ingress hostNetwork: true 这是一种直接定义Pod网络的方式。 如果在Pod中使用hostNetwork:true配置的话,在这种pod中运行的应用程序可以直接看到pod所在宿主机的网络接口。 以下是使用主机网络的pod的示例定义: apiVersion: v1 kind: Pod metadata: name: influxdb spec: hostNetwork: true containers : - name: influxdb image: influxdb 部署该Pod: $ kubectl create -f influxdb-hostnetwork.yml 访问该
mynginx-ingress 是上面创建的 release 名;nginx-stable/nginx-ingress 是在线 chart 名 $ helm upgrade --set controller.hostNetwork pull nginx-stable/nginx-ingress # 下载 chart $ tar zxf nginx-ingress-0.9.3.tgz # 解压缩 chart $ sed -i 's/hostNetwork : false/hostNetwork: true/g' nginx-ingress/values.yaml # 修改 values.yaml 内容。 比如修改 hostNetwork 的值为 true $ helm upgrade mynginx-ingress nginx-ingress -f nginx-ingress/values.yaml
tgz # 修改配置 # controller配置段修改 cd ingress-nginx vim values.yaml dnsPolicy: ClusterFirstWithHostNet hostNetwork kubernetes.github.io/ingress-nginx/ # 卸载 helm uninstall ingress-nginx -n ingress-nginx # 部署以及暴露方式 # DaemonSet+HostNetwork +nodeSelector # 用DaemonSet结合nodeselector来部署ingress-controller到特定的node上,然后使用HostNetwork直接把该pod与宿主机node
还需要注意的是max-pod是包含节点hostnetwork模式pod,hostnetwork模式pod不会占用容器网段ip,但是会算在max-pod的数量里面,那么这里就有另外一个问题了,节点虽然有cird - 3 和容器ip可以给pod使用,但是实际是调度不了那么多GlobalRouter模式pod到节点的,因为每个节点会有一些hostnetwork模式的pod,会占用一些pod数量,因此实际可分配给GlobalRouter 这里其实可以适当的给kubelet的pod数量增加一些,用来容纳hostnetwork模式pod,这里每个节点的容器网段ip就能充分利用了。 也是可以手动设置节点的max-pods,修改节点/etc/kubernetes/kubelet文件中MAX_PODS配置,但是这里改大会存在一个问题,就是节点的eni ip最大数量是有限制的,如果你将非hostnetwork 模式pod调度到节点,会出现分配不到eni-ip的情况,只有hostnetwork模式pod才能正常调度到节点。
hostNetwork: true 这是一种直接定义Pod网络的方式。 如果在Pod中使用hostNetwork:true配置的话,在这种pod中运行的应用程序可以直接看到pod启动的主机的网络接口。 以下是使用主机网络的pod的示例定义: apiVersion: v1 kind: Pod metadata: name: influxdb spec: hostNetwork: true containers : - name: influxdb image: influxdb 部署该Pod: $ kubectl create -f influxdb-hostnetwork.yml 访问该 的时候都可能被调度到不同的节点上,所有外部访问Pod的IP也是变化的,而且调度Pod的时候还需要考虑是否与宿主机上的端口冲突,因此一般情况下除非您知道需要某个特定应用占用特定宿主机上的特定端口时才使用hostNetwork
2m1 [root@k8smaster01 study]# curl 172.24.8.71:8081 示例2: [root@k8smaster01 study]# cat pod-hostnetwork.yaml 2 kind: Pod 3 metadata: 4 name: webapp2 5 labels: 6 app: webapp2 7 spec: 8 hostNetwork image: tomcat 12 ports: 13 - containerPort: 8080 14 hostPort: 8080 提示:通过设置Pod级别的hostNetwork 在设置hostNetwork=true时需要注意,在容器的ports定义部分如果不指定hostPort,则默认hostPort等于containerPort,如果指定了hostPort,则hostPort
pid", "--"]' overrides="$( cat <<EOT { "spec": { "nodeName": "$node", "hostPID": true, "hostNetwork infinity securityContext: privileged: true hostIPC: true hostPID: true hostNetwork /tasks/debug-application-cluster/debug-running-pod/ 对比nsenter方法,kubectl debug通过 shell 登录节点时只是共享了pid、hostNetwork
VirtualBox软件, 依次点击 “管理 -> 工具 -> Network Manager” , 在这个界面的“Host-only Networks”选项卡下,创建一个网络: 默认生成的配置是: Name: HostNetwork 192.168.56.1 Upper Bound: 192.168.56.199 然后在你要添加Host-Only网络的虚拟机上配置新增网络,添加启用网卡: 连接方式:Host-Only 名称选择上面我们新建的HostNetwork
DaemonSet+HostNetwork+nodeSelector hostNetwork模式不再需要创建一个nodePort的svc,而是直接在每个节点都创建一个ingress-controller 的容器,而且将该容器的网络模式设为hostNetwork。 使用hostNetwork的方式,ingress-controller将会使用的是物理机的DNS域名解析(即物理机的/etc/resolv.conf)。 用hostnetwork的另一个好处是,如果lvs用DR模式的话,是不支持端口映射的,这时候如果用nodeport,暴露非标准的端口,管理起来会很麻烦。 因为我们创建的ingress-controller采用的是hostnetwork模式,所以无需在创建nodePort形式的ingress-svc服务来把端口映射到节点主机上。