访问k8s内部pod service网络

kafa部署在k8s中，并且使用statefulset 方式部署，应用pod连接kafka 使用  kafka-0.kafka-hs.sy-platform-demo.svc.cluster.local.:9093， 如果k8s 外部开发测试，无法连接，所以需要外部网络与pod service网络打通

#kafka注册到zk中[zk: localhost:2181(CONNECTED) 5] get  /brokers/ids/0
{"jmx_port":-1,"timestamp":"1578999678086","endpoints":["PLAINTEXT://kafka-0.kafka-hs.sy-platform-demo.svc.cluster.local.:9093"],"host":"kafka-0.kafka-hs.sy-platform-demo.svc.cluster.local.","version":3,"port":9093}
cZxid = 0x1300000caa
ctime = Tue Jan 14 11:01:18 UTC 2020
mZxid = 0x1300000caa
mtime = Tue Jan 14 11:01:18 UTC 2020
pZxid = 0x1300000caa
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x36f841793790042
dataLength = 215
numChildren = 0

网络图谱如下

关闭完整的节点到节点BGP网格

如果要为Calico网络显式配置BGP拓扑，则需要关闭完整的节点到节点网格。有关 更改全局BGP设置的说明，nodeToNodeMeshEnabled 设置为flase

如果您是从头开始构建网络的，不需要完整的节点到节点网格，我们建议在配置节点之前关闭网格。如果要将网络从全网状拓扑更新为其他拓扑（例如，开始使用路由反射器群集来增加缩放比例），请在禁用网状结构之前配置适当的对等点，以确保服务的连续性。

注意： 会出现无法访问

先决条件：calicoctl 已安装并配置。

1 首先 是否具有default BGP配置资源

[[email protected] ceph_rbd]# calicoctl get bgpconfig default
Failed to get resources: resource does not exist: BGPConfiguration(default) with error: the server could not find the requested resource (get BGPConfigurations.crd.projectcalico.org default)  #没有创建过

2.请使用以下命令创建资源。在执行前，根据需要调整 nodeToNodeMeshEnabled和和asNumber线和值。

 cat << EOF | calicoctl create -f -
 apiVersion: projectcalico.org/v3
 kind: BGPConfiguration
 metadata:
   name: default
 spec:
   logSeverityScreen: Info
   nodeToNodeMeshEnabled: false
   asNumber: 63400

3. 如果资源确实存在，请使用以下命令检索它并将其保存到文件中。

calicoctl get bgpconfig default --export -o yaml > bgp.yaml

4 打开bgpconfig设置文件，修改nodeToNodeMeshEnabled或asNumber根据需要，然后保存该文件。有关这些设置的详细信息，请参考BGP配置资源。

vim bgp.yaml

5. 替换现有的BGP配置设置。

 calicoctl replace -f bgp.yaml

配置集群内网反射器（网关）

对于较大的部署，您可以禁用完整的节点到节点网格，并配置一些节点以提供集群内路由反射。这样，每个节点仍将获得所有工作负载路由，但使用的BGP连接数量要少得多。

  1. 确定一个或多个Calico节点充当路由反射器。只要该节点保持正常运行，就只需要一个节点，但是我们建议选择两个或三个节点，以便在其中一些节点需要停机时间进行维护时继续正确的路由传播。
  2. 修改每个节点的节点资源，以：
    • 将节点设置spec.bgp.routeReflectorClusterID为非空的群集ID，例如 224.0.0.1
    • 添加表明该节点是路由反射器的标签。

查看所有节点

[[email protected] ~]# calicoctl get node
NAME
master1
master2
master3
node1
node2
node3
node4

使用一个节点充当反射器

命令如下：calicoctl get node <node_name> --export -o yaml > node.yml

calicoctl get node node4 --export -o yaml > node4.yaml
apiVersion: projectcalico.org/v3
kind: Node
metadata:
  annotations:
    projectcalico.org/kube-labels: ‘{"beta.kubernetes.io/arch":"amd64","beta.kubernetes.io/os":"linux","kubernetes.io/arch":"amd64","kubernetes.io/hostname":"node4","kubernetes.io/os":"linux"}‘
  creationTimestamp: "2020-04-01T07:16:09Z"
  labels:
    beta.kubernetes.io/arch: amd64
    beta.kubernetes.io/os: linux
    i-am-a-route-reflector: "true"
    kubernetes.io/arch: amd64
    kubernetes.io/hostname: node4
    kubernetes.io/os: linux
  name: node4
  resourceVersion: "3249621"
  uid: b855402d-ff5c-469b-87e1-0208ebf2c90e
spec:
  bgp:
    ipv4Address: 172.16.230.28/24
    ipv4IPIPTunnelAddr: 10.20.3.64
    routeReflectorClusterID: 172.16.230.254    #添加

编辑node.yml，使其包括

metadata:
  labels:
    i-am-a-route-reflector: true
spec:
  bgp:
    routeReflectorClusterID: 172.16.230.254

然后应用更新的YAML。

calicoctl apply -f node4.yml

配置BGPPeer资源，以告知其他Calico节点与路由反射器节点对等：

calicoctl apply -f - <<EOF
kind: BGPPeer
apiVersion: projectcalico.org/v3
metadata:
  name: peer-to-rrs
spec:
  nodeSelector: !has(i-am-a-route-reflector)
  peerSelector: has(i-am-a-route-reflector)
EOF

配置BGPPeer资源，使路由反射器节点相互对等：

calicoctl apply -f - <<EOF
kind: BGPPeer
apiVersion: projectcalico.org/v3
metadata:
  name: rr-mesh
spec:
  nodeSelector: has(i-am-a-route-reflector)
  peerSelector: has(i-am-a-route-reflector)
EOF

配置IP-in-IP 模式

  • Always: 永远进行 IPIP 封装(默认)
  • CrossSubnet: 只在跨网段时才进行 IPIP 封装，适合有 Kubernetes 节点在其他网段的情况，属于中肯友好方案
  • Never: 从不进行 IPIP 封装，适合确认所有 Kubernetes 节点都在同一个网段下的情况

将IP-in-IP ipipMode设置Always为时，Calico将使用IP-in-IP路由从启用了Calico的主机发出的所有流量到IP池中的所有Calico网络容器和VM。

使用的IP-in-IP ipipMode的CrossSubnet，IP-in-IP封装也可以选择性地执行，仅用于跨越子网边界的流量。

导出ippool配置

calicoctl get ippool default-ipv4-ippool -o yaml > ippool.yaml

修改 ipipMode 值为 CrossSubnet

[[email protected] ~]# cat ippool.yaml
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  creationTimestamp: "2020-04-01T07:58:10Z"
  name: default-ipv4-ippool
  resourceVersion: "21004"
  uid: dd5b3e61-8a58-44d0-aac5-d248430a017c
spec:
  blockSize: 26
  cidr: 10.20.0.0/16
  ipipMode: CrossSubnet
  natOutgoing: true
  nodeSelector: all()
  vxlanMode: Never

执行

calicoctl apply -f ippool.yaml

添加路由：

172.16.230.249网段

route add 10.20.0.0 mask 255.255.0.0  172.16.230.28

route add 10.254.0.0 mask 255.255.192.0  172.16.230.28

参考：

https://mritd.me/2019/06/18/calico-3.6-forward-network-traffic/

https://docs.projectcalico.org/v3.6/networking/bgp#configuring-in-cluster-route-reflectors

https://docs.projectcalico.org/v3.6/networking/ip-in-ip

原文地址：https://www.cnblogs.com/fengjian2016/p/12696966.html

时间： 2024-10-29 04:39:32

访问k8s内部pod service网络的相关文章

k8s实战之Service

一.概述 为了适应快速的业务需求,微服务架构已经逐渐成为主流,微服务架构的应用需要有非常好的服务编排支持,k8s中的核心要素Service便提供了一套简化的服务代理和发现机制,天然适应微服务架构,任何应用都可以非常轻易地运行在k8s中而无须对架构进行改动: k8s分配给Service一个固定IP,这是一个虚拟IP(也称为ClusterIP),并不是一个真实存在的IP,而是由k8s虚拟出来的.虚拟IP的范围通过k8s API Server的启动参数 --service-cluster-ip-ran

kubernetes基本概念 pod, service

k8s的部署架构 kubernetes中有两类资源,分别是master和nodes,master和nodes上跑的服务如下图, kube-apiserver | kubelet kube-controller-manager | kube-scheduler | kube-proxy ---------------------- -------------------- k8s master node (non-master) master:负责管理整个集群,例如,对应用进行调度(扩缩).维护应

Docker Kubernetes Service 网络服务代理模式详解

Docker Kubernetes  Service 网络服务代理模式详解 Service service是实现kubernetes网络通信的一个服务 主要功能:负载均衡.网络规则分布到具体pod 注:kubernetes deployment服务分配服务器负载均衡VIP只能NODE节点单独访问,这里需要外网用户可以放问到容器内,这里就需要用到service. 网络代理模式 kube-proxy v1.0中只支持userspace模式,在v1.1中,添加了iptables代理,在v1.2开始ip

在kubernetes 集群内访问k8s API服务

所有的 kubernetes 集群中账户分为两类,Kubernetes 管理的 serviceaccount(服务账户) 和 useraccount(用户账户).基于角色的访问控制(“RBAC”)使用“rbac.authorization.k8s.io”API 组来实现授权控制,允许管理员通过Kubernetes API动态配置策略. API Server 内部通过用户认证后,然后进入授权流程.对合法用户进行授权并且随后在用户访问时进行鉴权,是权限管理的重要环节.在 kubernetes 集群中

idou老师教你学Istio 14：如何用K8S对Istio Service进行流量健康检查

Istio利用k8s的探针对service进行流量健康检查,有两种探针可供选择,分别是liveness和readiness: liveness探针用来侦测什么时候需要重启容器.比如说当liveness探针捕获到程序运行时出现的一个死锁,这种情况下重启容器可以让程序更容易可用. readiness探针用来使容器准备好接收流量.当所有容器都ready时被视为pod此时ready.比如说用这种信号来控制一个后端服务,当pod没有到ready状态时,服务会从负载均衡被移除. 使用场景: liveness

K8s的POD连接数据库时报错

[[email protected] xxxx]# ./showlog.sh dr iff-dr-1128668949-lb90g 2017-09-29 03:21:57,575 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 2017-09-29 03:21:57,612 INFO [org.wildfly.s

K8s之Pod进阶

注意此篇文章接上篇:K8s之Pod资源管理及创建Harbor私有镜像仓库https://blog.51cto.com/14464303/2471369 一.资源限制: pod和container的资源请求和限制: spec.containers[].resources.limits.cpu #cpu上限 spec.containers[].resources.limits.memory #内存上限 spec.containers[].resources.requests.cpu #创建时分配的基

通过ajax访问Tomcat服务器web service接口时出现No &#39;Access-Control-Allow-Origin&#39; header问题的解决办法

问题描述 通过ajax访问Web服务器(Tomcat7.0.42)中的json web service接口的时候,报以下跨域问题: XMLHttpRequest cannot load http://localhost:8080/get-employees-by-name/name/admin. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhos

TI C66x DSP 四种内存保护问题 -之- 外设访问corePac内部资源时的内存保护问题

Problem Description Josnch星球是一个赌博之风盛行的星球.每个人一出生就有一定数额的钱,之后的所有收入只能由赌博获得(OMG,如果RP不好,输光了所有的钱...)假设赌博公司的某场赌博有N个结果,每个结果能获得的赔率比分别是a[1],a[2]...a[N].假设现在XXX有X块钱,问他选择怎样的策略才能使得最坏情况下回报最大(假设N个结果中只有一个是有回报的,X块钱必须全部用在这次赌博上,赔率比就是a[i],假设你在第 i 个结果中投入了 y 块钱,那么你的回报是 y *