OSPF
1.OSPF是什么
开放最短路径优先,一种链路状态路由协议,使用SPF算法寻址
2.工作过程
先建立邻居,然后同步链路状态数据库,再计算最优路由路径
3.如何更改OSPF域中的Route ID
#clear IP OSPF process authority
4.关键属性
- Equal Cost Routes管理: CEF Load对应
- 协议类型:链路状态
- 传输:IP(89)
- 度量:const(带宽)
- 标准:RFC2328(OSPFv2)、RFC2740(OSPFv3/IPv6)
5.邻居关系变为邻接关系 - LSR数据包、链路状态、LSU数据包
- 双向通告
- 数据库同步,描述数据包的切换、链接
- 数据库同步完成,两个Router被测量为相邻
6.哪四种路由器类型 - 自治系统边界路由器,将外部路由通告到OSPF域的路由器
- 内部路由器,所有接口都属于同一区域的路由器
- 区域边界路由器,在多个区域中具有接口的路由器
- 骨干路由器,在区域0的路由器内部的路由器
7.特点是什么 - OSPF使用成本作为其度量,它是根据链路的带宽计算的
- OSPF是一个支持VLSM和CIDR的无类路由过程
- OSPF路由的距离为110
- 没有跳数限制
- 允许创建区域和独立系统
8.解释不同OSPF的功能和工作原理,并且什么类型用于OSPF中的协议间通信 - 使用LSA(Link-State Advertisements)通告直接相关链路状态
- 其中一个链接发生更改时,OSPF会通知更新,并且只会通过更新发送差异,LSA每30分钟额外刷新一次
- 使用SPF算法决定最短路径
- Type 3 LSA 用于区域间通信,其他协议和外部路由的通信使用Type4和5
9.是否可以让一侧编号而另一侧未编号 - 不能,不起作用,会导致数据库不一致,从而阻止将路由安装在引导表中
10.DR和BDR解决了什么 - 过渡LSA泛洪
- 邻接数高
11.邻接是什么意思 - 邻接指的是到邻居的理论上的链路,可以通过链路发送链路状态通告
12.链路状态重传间隔是什么 - OSPF必须发送对每个新的常规LSA的识别,LSA被重新传输,直到它们被批准,链路状态重传间隔定义重传之间的时间
-
IP OSPF retransmit-interval
13.说出五种OSPF数据包类型
- DBD、HELLO、LSU、LSR、LSack
14.子网关键字有什么用 - 没有子网关键字,则只会重新分配未直接连接到路由器的主网络地址
15.有几种LSA - External LSA、Network LSA、ASBR Summary LSA、Network Summary LSA、Router LSA
16.将优先级设为“0”的Route会发生什么 - 不参与DR/BDR的选举
17.没有骨干区域能使用OSPF吗 - 可以,但只有区域内通信,没有骨干区域就无法实现区域之间的通信
18.多播地址 - 224.0.0.5和224.0.0.6
19.Route ID是什么 - 用于识别路由器的标识符,是一个32位数字
20.OSPF定时器 - Dead Interval:定义了扩展路由器在宣布邻居死亡之前将如何等待hello数据包
- Hello Interval:定义了OSPF路由器向其他OSPF路由器发送hello数据包的频率
Kubernetes
一个目标:容器操作
自动化容器操作的开源平台。这些容器操作包括:部署、调度和节点集群间扩展。
具体功能:
- 自动化容器部署和复制。
- 实时弹性收缩容器规模。
- 容器编排成组,并提供容器间的负载均衡。
- 调度:容器在哪个机器上运行。
组成:
- kubectl:客户端命令行工具,作为整个系统的操作入口。
- kube-apiserver:以 REST API 服务形式提供接口,作为整个系统的控制入口。
- kube-controller-manager:执行整个系统的后台任务,包括节点状态状况、Pod 个数、Pods 和Service 的关联等。
- kube-scheduler:负责节点资源管理,接收来自 kube-apiserver 创建 Pods 任务,并分配到某个节点。
- etcd:负责节点间的服务发现和配置共享。
- kube-proxy:运行在每个计算节点上,负责 Pod 网络代理。定时从 etcd 获取到 service 信息来做相应的策略。
- kubelet:运行在每个计算节点上,作为 agent,接收分配该节点的 Pods 任务及管理容器,周期性获取容器状态,反馈给 kube-apiserver。
- DNS:一个可选的 DNS 服务,用于为每个 Service 对象创建 DNS 记录,这样所有的 Pod 就可以通过 DNS 访问服务了。
两地三中心
两地三中心包括本地生产中心、本地灾备中心、异地灾备中心。
k8s 使用 etcd 组件作为一个高可用、强一致性的服务发现存储仓库。用于配置共享和服务发现。
它作为一个受到 Zookeeper 和 doozer 启发而催生的项目。除了拥有他们的所有功能之外,还拥有以下 4 个特点:
- 简单:基于 HTTP+JSON 的 API 让你用 curl 命令就可以轻松使用。
- 安全:可选 SSL 客户认证机制。
- 快速:每个实例每秒支持一千次写操作。
- 可信:使用 Raft 算法充分实现了分布式。
四层服务发现
k8s 提供了两种方式进行服务发现:
环境变量:当创建一个 Pod 的时候,kubelet 会在该 Pod 中注入集群内所有 Service 的相关环境变量。需要注意的是,要想一个 Pod 中注入某个 Service 的环境变量,则必须 Service 要先比该 Pod 创建。这一点,几乎使得这种方式进行服务发现不可用。 比如,一个 ServiceName 为 redis-master 的 Service,对应的 ClusterIP:Port 为 10.0.0.11:6379,则对应的环境变量为:
- REDIS_MASTER_SERVICE_HOST=10.0.0.11
- REDIS_MASTER_SERVICE_PORT=6379
- REDIS_MASTER_PORT=tcp://10.0.0.11:6379
- REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
- REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
- REDIS_MASTER_PORT_6379_TCP_PORT=6379
- REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11
DNS:可以通过 cluster add-on 的方式轻松的创建 KubeDNS 来对集群内的 Service 进行服务发现。
以上两种方式,一个是基于 TCP,DNS 基于 UDP,它们都是建立在四层协议之上。
五种 Pod 共享资源
Pod 是 k8s 最基本的操作单元,包含一个或多个紧密相关的容器。
一个 Pod 可以被一个容器化的环境看作应用层的“逻辑宿主机”;一个 Pod 中的多个容器应用通常是紧密耦合的,Pod 在 Node 上被创建、启动或者销毁;每个 Pod 里运行着一个特殊的被称之为 Volume 挂载卷,因此他们之间通信和数据交换更为高效。在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个 Pod 中。
一个 Pod 中的应用容器共享五种资源:
- PID 命名空间:Pod 中的不同应用程序可以看到其他应用程序的进程 ID。
- 网络命名空间:Pod 中的多个容器能够访问同一个IP和端口范围。
- IPC 命名空间:Pod 中的多个容器能够使用 SystemV IPC 或 POSIX 消息队列进行通信。
- UTS 命名空间:Pod 中的多个容器共享一个主机名。
- Volumes(共享存储卷):Pod 中的各个容器可以访问在 Pod 级别定义的 Volumes。
- Pod 的生命周期通过 Replication Controller 来管理;通过模板进行定义,然后分配到一个 Node 上运行,在 Pod 所包含容器运行结束后,Pod 结束。
Kubernetes 为 Pod 设计了一套独特的网络配置,包括为每个 Pod 分配一个IP地址,使用 Pod 名作为容器间通信的主机名等。
同一个 Pod 里的容器之间仅需通过 localhost 就能互相通信。
六个 CNI 常用插件
CNI(Container Network Interface)容器网络接口是 Linux 容器网络配置的一组标准和库,用户需要根据这些标准和库来开发自己的容器网络插件。CNI 只专注解决容器网络连接和容器销毁时的资源释放,提供一套框架。所以 CNI 可以支持大量不同的网络模式,并且容易实现。
- Loopback
- Bridge
- PTP
- MACvlan
- IPvlan
- 3rd-party
七层负载均衡
提负载均衡就不得不先提服务器之间的通信。
IDC(Internet Data Center)也可称数据中心、机房,用来放置服务器。IDC 网络是服务器间通信的桥梁。
路由器、交换机、MGW/NAT 都是网络设备,按照性能、内外网划分不同的角色。
-
内网接入交换机:也称为 TOR(top of rack),是服务器接入网络的设备。每台内网接入交换机下联 40-48 台服务器,使用一个掩码为 /24 的网段作为服务器内网网段。
-
内网核心交换机:负责 IDC 内各内网接入交换机的流量转发及跨 IDC 流量转发。
-
MGW/NAT:MGW 即 LVS 用来做负载均衡,NAT 用于内网设备访问外网时做地址转换。
-
外网核心路由器:通过静态互联运营商或 BGP 互联美团统一外网平台。
-
二层负载均衡:基于 MAC 地址的二层负载均衡。
-
三层负载均衡:基于 IP 地址的负载均衡。
-
四层负载均衡:基于 IP+端口 的负载均衡。
-
七层负载均衡:基于 URL 等应用层信息的负载均衡。
上面四层服务发现讲的主要是 k8s 原生的 kube-proxy 方式。k8s 关于服务的暴露主要是通过 NodePort 方式,通过绑定 minion 主机的某个端口,然后进行 Pod 的请求转发和负载均衡,但这种方式有下面的缺陷:
- Service 可能有很多个,如果每个都绑定一个 Node 主机端口的话,主机需要开放外围的端口进行服务调用,管理混乱。
- 无法应用很多公司要求的防火墙规则。
理想的方式是通过一个外部的负载均衡器,绑定固定的端口,比如 80;然后根据域名或者服务名向后面的 Service IP 转发。
Kubernetes 给出的方案就是 Ingress(1.30.x版本改为Gateway API)。这是一个基于七层的方案。