Skip to content

Commit ca250ef

Browse files
andrewbytecoderandrewbytecoder
committed
添加calico网络模式说明
1 parent e2b1d34 commit ca250ef

7 files changed

+229
-1
lines changed

‎calico/attachments/Pasted image 20250912173841.png

139 KB
Loading

‎calico/attachments/Pasted image 20250912175646.png

97.2 KB
Loading

‎calico/attachments/Pasted image 20250912175656.png

97.2 KB
Loading

‎calico/attachments/Pasted image 20250912180507.png

82.2 KB
Loading

‎calico/attachments/Pasted image 20250912180900.png

79.3 KB
Loading

‎calico/calico.md

Lines changed: 125 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,134 @@
1-
## Calico
1+
## calico
2+
calico是一个比较有趣的虚拟网络解决方案，完全利用路由规则实现动态组网，通过BGP协议通告路由。
3+
calico的好处是endpoints组成的网络是单纯的三层网络，报文的流向完全通过路由规则控制，没有overlay等额外开销。
4+
calico的endpoint可以漂移，并且实现了acl。
5+
calico的缺点是路由的数目与容器数目相同，非常容易超过路由器、三层交换、甚至node的处理能力，从而限制了整个网络的扩张。
6+
calico的每个node上会设置大量（海量)的iptables规则、路由，运维、排障难度大。
7+
calico的原理决定了它不可能支持VPC，容器只能从calico设置的网段中获取ip。
8+
calico目前的实现没有流量控制的功能，会出现少数容器抢占node多数带宽的情况。
9+
calico的网络规模受到BGP网络规模的限制。
10+
11+
### calico 组件
212

313
Calico组件主要架构由Felix、Confd、BIRD组成
414

515
- Felix 运行在每一台 Host 的 agent 进程，Felix负责刷新主机路由和ACL规则等，以便为该主机上的 Endpoint 正常运行提供所需的网络连接和管理。进出容器、虚拟机和物理主机的所有流量都会遍历Calico，利用Linux内核原生的路由和iptables生成的规则。是负责Calico Node运行并作为每个节点Endpoint端点的守护程序，它负责管理当前主机中的Pod信息，与集群etcd服务交换集群Pod信息，并组合路由信息和ACL策略。
616
- Confd是负责存储集群etcd生成的Calico配置信息，提供给BIRD层运行时使用。
717
- BIRD（BIRD Internet Routing Daemon）是核心组件，Calico中的BIRD特指BIRD Client和BIRD Route Reflector，负责主动读取Felix在本机上设置的路由信息，并通过BGP广播协议在数据中心中进行分发路由
18+
-
19+
### BGP Speaker 全互联模式(node-to-node mesh)
20+
全互联模式，就是一个BGP Speaker需要与其它所有的BGP Speaker建立bgp连接(形成一个bgp mesh)。
21+
网络中bgp总连接数是按照O(n^2)增长的，有太多的BGP Speaker时，会消耗大量的连接。
22+
calico默认使用全互联的方式，扩展性比较差，只能支持小规模集群:
23+
24+
> say 50 nodes - although this limit is not set in stone and Calico has been deployed with over 100 nodes in a full mesh topology
25+
26+
可以打开/关闭全互联模式：
27+
```bash
28+
calicoctl config set nodeTonodeMesh off
29+
calicoctl config set nodeTonodeMesh on
30+
```
31+
32+
### BGP Speaker RR模式
33+
34+
RR模式，就是在网络中指定一个或多个BGP Speaker作为Router Reflection，RR与所有的BGP Speaker建立BGP连接。
35+
每个BGP Speaker只需要与RR交换路由信息，就可以得到全网路由信息。
36+
RR则必须与所有的BGP Speaker建立BGP连接，以保证能够得到全网路由信息。
37+
在calico中可以通过Global Peer实现RR模式。
38+
Global Peer是一个BGP Speaker，需要手动在calico中创建，所有的node都会与Global peer建立BGP连接。
39+
40+
>A global BGP peer is a BGP agent that peers with every calico node in the network. A typical use case for a global peer might be a mid-scale deployment where all ofthe calico nodes are on the same L2 network and are each peering with the same Route Reflector (or set of Route Reflectors).
41+
42+
**关闭了全互联模式后，再将RR作为Global Peers添加到calico中**，calico网络就切换到了RR模式，可以支撑容纳更多的node。
43+
calico中也可以通过node Peer手动构建BGP Speaker（也就是node）之间的BGP连接。
44+
node Peer就是手动创建的BGP Speaker，只有指定的node会与其建立连接。
45+
46+
>A BGP peer can also be added at the node scope, meaning only a single specified node will peer with it. BGP peer resources of this nature must specify a node to inform calico which node this peer is targeting.
47+
48+
49+
因此，可以为每一个node指定不同的BGP Peer，实现更精细的规划。
50+
例如当集群规模进一步扩大的时候，可以使用[AS Per Pack model](http://docs.projectcalico.org/v2.1/reference/private-cloud/l3-interconnect-fabric#the-as-per-rack-model "AS Per Rack model"):
51+
52+
每个机架是一个AS
53+
node只与所在机架TOR交换机建立BGP连接
54+
TOR交换机之间作为各自的ebgp全互联
55+
56+
57+
### calico 网络部署
58+
calico网络对底层的网络的要求很少，只要求node之间能够通过IP联通。
59+
在calico中，全网路由的数目和endpoints的数目一致，通过为node分配网段，可以减少路由数目，但不会改变数量级。
60+
如果有1万个endpoints，那么就至少要有一台能够处理1万条路由的设备。
61+
无论用哪种方式部署始终会有一台设备上存放着calico全网的路由。
62+
当要部署calico网络的时候，第一步就是要确认，网络中处理能力最强的设备最多能设置多少条路由。
63+
64+
#### calico在Ethernet interconnect fabric中的部署方式
65+
[calico over an Ethernet interconnect fabric](http://docs.projectcalico.org/v2.1/reference/private-cloud/l2-interconnect-fabric "calico over an Ethernet interconnect fabric")中介绍了在Ethernet interconnect fabric部署calico网络方案。在每个vlan中部署一套calico。
66+
![[Pasted image 20250912173841.png]]
67+
为了保证链路可靠，图中设计了四个并列的二层网，形成fabric。
68+
每个node同时接入四个二层网络，对应拥有四个不同网段的IP。
69+
在每个二层网络中，node与node之间用RR模式建立BGP通信链路:
70+
71+
有四个网段，路由等价，那么进行数据分流的时候会进行平均分配，这样能增加网络的吞吐能力
72+
当从node上去访问另一个node上的endpoint的时候，会有四条下一跳为不同网段的等价路由。
73+
根据[ECMP](https://en.wikipedia.org/wiki/Equal-cost_multi-path_routing "ECMP")协议，报文将会平均分配给这四个等价路由，提高了可靠性的同时增加了网络的吞吐能力
74+
75+
#### calico在ip fabric中的部署方式
76+
如果底层的网络是ip fabric的方式，三层网络是可靠的，只需要部署一套calico。
77+
78+
剩下的关键点就是怎样设计BGP网络，[calico over ip fabrics](https://docs.projectcalico.org/v2.1/reference/private-cloud/l3-interconnect-fabric "calico over ip fabrics")中给出两种设计方式:
79+
1. AS per rack: 每个rack(机架)组成一个AS，每个rack的TOR交换机与核心交换机组成一个AS
80+
2. AS per server: 每个node做为一个AS，TOR交换机组成一个transit AS
81+
这两种方式采用的是[Use of BGP for routing in large-scale data centers](https://tools.ietf.org/html/draft-ietf-rtgwg-bgp-routing-large-dc-11 "Use of BGP for routing in large-scale data centers")中的建议。
82+
83+
##### AS per rack
84+
1. 一个机架作为一个AS，分配一个AS号，node是ibgp，TOR交换机是ebgp
85+
2. node只与TOR交换机建立BGP连接，TOR交换机与机架上的所有node建立BGP连接
86+
3. 所有TOR交换机之间以node-to-node mesh方式建立BGP连接
87+
88+
TOR交换机之间可以是接入到同一个核心交换机二层可达的，也可以只是IP可达的。
89+
90+
TOR二层联通:
91+
![[Pasted image 20250912175646.png]]
92+
93+
94+
95+
TOR三层联通：
96+
![[Pasted image 20250912175656.png]]
97+
98+
每个机架上node的数目是有限的，BGP压力转移到了TOR交换机。当机架数很多，TOR交换机组成BGP mesh压力会过大。
99+
```
100+
EndpointA发出报文 --> nodeA找到了下一跳地址nodeB --> 报文送到TOR交换机A --> 报文送到核心交换机
101+
|
102+
v
103+
EndpointB收到了报文 <-- nodeB收到了报文 <-- TOR交换机B收到了报文 <-- 核心交换机将报文送达TOR交换机B
104+
```
105+
106+
###### AS per server
107+
1. 每个TOR交换机占用一个AS
108+
2. 每个node占用一个AS
109+
3. node与TOR交换机交换BGP信息
110+
4. 所有的TOR交换机组成BGP mesh，交换BGP信息
111+
这种方式消耗了大量的AS，[RFC 4893 - BGP Support for Four-octet AS Number Space](http://www.faqs.org/rfcs/rfc4893.html "RFC 4893 - BGP Support for Four-octet AS Number Space")中考虑将AS号增加到32位。
112+
113+
不是特别明白这种方式的好处在哪里。
114+
115+
TOR二层联通:
116+
![[Pasted image 20250912180507.png]]
117+
TOR三层联通:
118+
![[Pasted image 20250912180900.png]]
119+
#### 优化：“Downward Default model”减少需要记录的路由
120+
Downward Default Model在上面的几种组网方式的基础上，优化了路由的管理。
121+
在上面的三种方式中，每个node、每个TOR交换机、每个核心交换机都需要记录全网路由。
122+
“Downward Default model”模式中:
123+
1. 每个node向上(TOR)通告所有路由信息，而TOR向下(node)只通告一条默认路由
124+
2. 每个TOR向上(核心交换机)通告所有路由，核心交换机向下(TOR)只通告一条默认路由
125+
3. node只知晓本地的路由
126+
4. TOR只知道接入到自己的所有node上的路由
127+
5. 核心交换机知晓所有的路由
128+
129+
130+
131+
8132

9133
### 网络模型
10134

‎k8s/grafana.md

Lines changed: 104 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -780,3 +780,107 @@ grafana支持播放列表，添加之后可以在大屏或者其他设备上全
780780

781781

782782
## Panels and visualizations
783+
784+
785+
786+
787+
788+
## grafana常见问题
789+
790+
791+
792+
### url递归问题
793+
当关闭grafana匿名登录，并添加子路径时，必须要添加上令牌轮换和会话超时，否则url会进行死循环，疯狂的进行递归
794+
795+
```yaml
796+
- env:
797+
- name: GF_AUTH_BASIC_ENABLE
798+
value: "true"
799+
- name: GF_USERS_DEFAULT_THEME
800+
value: "dark"
801+
- name: GF_SECURITY_ALLOW_EMBEDDING
802+
value: "true"
803+
# 开启子路径之前需要确保 令牌轮换和会话超时 配置ok
804+
- name: GF_AUTH_TOKEN_ROTATION_INTERVAL_MINUTES
805+
value: "30"
806+
- name: GF_AUTH_LOGIN_MAXIMUM_INACTIVE_LIFETIME_DURATION
807+
value: "7d"
808+
- name: GF_AUTH_LOGIN_MAXIMUM_LIFETIME_DURATION
809+
value: "30d"
810+
# 添加子路径
811+
- name: GF_SERVER_ROOT_URL
812+
value: "%(protocol)s://%(domain)s:%(http_port)s/grafanaProxyApi/"
813+
# 要确保和上述子路径绑定出现，确保grafana的子资源也是走的字路径
814+
- name: GF_SERVER_SERVE_FROM_SUB_PATH
815+
value: "true"
816+
817+
- name: "GF_LOG_MODE"
818+
value: "file"
819+
- name: "GF_LOG_FILE_MAX_LINES"
820+
value: "100000"
821+
- name: "GF_LOG_FILE_MAX_SIZE_SHIFT"
822+
value: "24"
823+
- name: "GF_LOG_FILE_MAX_DAYS"
824+
value: "365"
825+
```
826+
827+
828+
```ini
829+
[auth]
830+
# 禁用匿名登录
831+
[auth.anonymous]
832+
enabled = false
833+
834+
# 令牌轮换和会话超时
835+
token_rotation_interval_minutes = 30
836+
login_maximum_inactive_lifetime_duration = 7d
837+
login_maximum_lifetime_duration = 30d
838+
839+
# 禁用登录表单（如果使用 SSO）
840+
disable_login_form = true
841+
842+
# 代理认证（如果适用）
843+
[auth.proxy]
844+
enabled = false
845+
enable_login_token = false
846+
```
847+
848+
849+
### 登录grafana一直显示重定向过多问题
850+
其实真是问题不是重定向问题，而是因为在多主的情况下，会安装多个grafana，多个grafana之间在前端进行访问的时候是轮流访问的，但是认证信息下发的时候其实只下发给了一个grafana，如果下次访问访问到没有认证信息的grafana，会导致login失败，因为login等失败，界面会误认为是重定向过多导致的报错（因为实际使用中使用Nginx进行了重定向）
851+
852+
#### 解决方法1
853+
既然是因为客户端访问svc重定向导致的，那么只需要保证前端访问时一直找同一个grafana服务就行了，因此可通过在service中添加客户端亲和性来解决这个问题
854+
```yaml
855+
apiVersion: v1
856+
kind: Service
857+
metadata:
858+
labels:
859+
app.kubernetes.io/component: grafana
860+
app.kubernetes.io/name: grafana
861+
app.kubernetes.io/part-of: kube-prometheus
862+
app.kubernetes.io/version: 11.5.2
863+
name: grafana
864+
namespace: base-services
865+
spec:
866+
ports:
867+
- name: http
868+
port: 3000
869+
targetPort: http
870+
nodePort: 30002
871+
type: NodePort
872+
selector:
873+
app.kubernetes.io/component: grafana
874+
app.kubernetes.io/name: grafana
875+
app.kubernetes.io/part-of: kube-prometheus
876+
# 添加客户端亲和性，保证同一个前端访问时一直访问的是同一个grafana后端 （默认3h）
877+
sessionAffinity: ClientIP
878+
```
879+
880+
但是这样解决有以下问题：
881+
1. 必须保证会话超时时间和前端的会话一致否则会造成下次访问超过客户端亲和性时间，还是会报重定向过多问题
882+
2. 如果另外一个人通过界面访问同样的ui，可能会访问到另外一个grafana，因为开启了grafana登录，如果两个人输入的用户名密码不一致，那么就会对外表现同样的ui访问grafana界面需要输入不同的用户信息才能登录
883+
884+
#### 解决方法2
885+
将grafana的deployment中的replicas设置为1，这样无论前端如何访问监控界面访问的都是同一个grafana后端，这样能解决以上所有问题
886+

0 commit comments

Comments
 (0)