8. io

本文详细介绍了Java中的IO模型,从同步阻塞的BIO,到非阻塞的NIO,再到异步非阻塞的AIO。讨论了NIO中的缓冲区、选择器、多路复用器等核心概念,并对比了同步与异步、阻塞与非阻塞的区别。重点阐述了AIO如何实现线程结束后的主动通知,以及NIO在Netty、Dubbo、ZooKeeper等框架中的应用。

io,读写,指的是内存,
读是内存从文件网络等读取数据
写是内存写数据到文件网络等

bio(同步阻塞io)

叫一个线程停留在一个水壶那,直到这个水壶烧开,才去处理下一个水壶
一个请求创建一个线程

nio(java的nio就是linux的多路复用io)Netty、Dubbo、ZooKeeper等都是基于NIO方式实现

  1. bio面向字节流,nio面向块(buffer)
  2. 直接内存(非堆内存),减少拷贝次数(原来是堆内存拷贝到非堆内存,在拷贝到缓冲区)
  3. 内核和磁盘io通过channel,不占用cpu资源(原来调用io资源需要cpu参与)
  4. 多路复用器selector(检查多个channel是否准备好),select,epoll

所有数据都通过Buffer对象处理,所以,您永远不会将字节直接写入到Channel中,相反,您是将数据写入到Buffer中;同样,您也不会从Channel中读取字节,而是将数据从Channel读入Buffer,再从Buffer获取这个字节
在这里插入图片描述

异步 I/O 的一个优势在于,它允许您同时根据大量的输入和输出执行 I/O。同步程序常常要求助于轮询,或者创建许许多多的线程以处理大量的连接。使用异步 I/O,您可以监听任何数量的通道上的事件,不用轮询,也不用额外的线程。

Selector它可以注册到很多个Channel上,监听各个Channel上发生的事件,并且能够根据事件情况决定Channel读写。这样,通过一个线程管理多个Channel,就可以处理大量网络连接了。
在这里插入图片描述
在这里插入图片描述

一旦调用了select()方法,它就会返回一个数值,表示一个或多个通道已经就绪,然后你就可以通过调用selector.selectedKeys()方法返回的SelectionKey集合来获得就绪的Channel。请看演示方法:

Set selectedKeys = selector.selectedKeys();

当你通过Selector注册一个Channel时,channel.register()方法会返回一个SelectionKey对象,这个对象就代表了你注册的Channel。这些对象可以通过selectedKeys()方法获得。你可以通过迭代这些selected key来获得就绪的Channel

AIO(异步非阻塞,无需轮询,线程结束后主动通知)

为每个水壶上面装了一个开关,水烧开之后,水壶会自动通知我水烧开了。

同步&异步

同步
发送一个请求,等待返回,再发送下一个请求,同步可以避免出现死锁,脏读的发生。

异步
发送一个请求,不等待返回,随时可以再发送下一个请求,可以提高效率,保证并发。

阻塞&非阻塞

阻塞
传统的IO流都是阻塞式的。也就是说,当一个线程调用read()或者write()方法时,该线程将被阻塞,直到有一些数据读读取或者被写入,在此期间,该线程不能执行其他任何任务。在完成网络通信进行IO操作时,由于线程会阻塞,所以服务器端必须为每个客户端都提供一个独立的线程进行处理,当服务器端需要处理大量的客户端时,性能急剧下降。

非阻塞
JavaNIO是非阻塞式的。当线程从某通道进行读写数据时,若没有数据可用时,该线程会去执行其他任务。线程通常将非阻塞IO的空闲时间用于在其他通道上执行IO操作,所以单独的线程可以管理多个输入和输出通道。因此NIO可以让服务器端使用一个或有限几个线程来同时处理连接到服务器端的所有客户端。
在这里插入图片描述

---------------------------------------------------

基本概念

缓冲区

调用read,DMA拷贝到内核缓冲区,再拷贝到用户缓冲区
在这里插入图片描述
硬件设备通常不能直接访问用户空间(虚拟内存地址)

虚拟内存(需要映射)

在这里插入图片描述
通过内存映射,减少了内核与用户空间数据的拷贝

虚拟内存分页,存在于外部磁盘存储,MMU管理内存映射关系,通过页错误来替换内存与磁盘的页
在这里插入图片描述

文件io

用户使用read和write操作内存,在内核空间 的文件系统页与用户空间的内存区之间移动数据,一次以上的拷贝操作几乎总是免不了的
在这里插入图片描述
文件锁定

流io
就绪型io

选择器

缓冲区连接通道,通道连接套接字或文件
通道注册到选择器上,注册成功后返回选择键(SelectionKey,包含通道,选择器,感兴趣的操作,ready的集合)(关联通道和是否就绪,调用选择器的select更新就绪状态)
选择器管理着被注册的通道集合的信息和它们的就绪状态,已选择的键的集合
可选择通道:这个抽象类提供了实现通道的可选择性所需要的公共方法,可以指定对 那个选择器而言,那种操作是感兴趣的;FileChannel 对象不是可选择的,因为它们没有继承 SelectableChannel(见图 4-2)。 所有 socket 通道都是可选择的
在这里插入图片描述

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml namespace/tigera-operator created customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/bgpfilters.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/caliconodestatuses.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/ipreservations.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/kubecontrollersconfigurations.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/apiservers.operator.tigera.io created customresourcedefinition.apiextensions.k8s.io/imagesets.operator.tigera.io created customresourcedefinition.apiextensions.k8s.io/tigerastatuses.operator.tigera.io created serviceaccount/tigera-operator created clusterrole.rbac.authorization.k8s.io/tigera-operator created clusterrolebinding.rbac.authorization.k8s.io/tigera-operator created deployment.apps/tigera-operator created The CustomResourceDefinition "installations.operator.tigera.io" is invalid: metadata.annotations: Too long: must have at most 262144 bytes yousatech@Rack-Server:~$ kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/custom-resources.yaml apiserver.operator.tigera.io/default created error: resource mapping not found for name: "default" namespace: "" from "https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/custom-resources.yaml": no matches for kind "Installation" in version "operator.tigera.io/v1" ensure CRDs are installed first
最新发布
11-07
<think>根据用户描述,在单机版 Kubernetes v1.28.15 中安装 Calico v3.26.1 时遇到两个错误: 1. CustomResourceDefinition "installations.operator.tigera.io" 的元数据注释过长(metadata.annotations: Too long) 2. 找不到 "Installation" 资源类型的匹配版本 结合引用内容分析: 引用[1]提到:直接使用 `kubectl apply -f` 安装可能会因为 CRD 的 annotations 过长而报错(超过 262144 字节的限制)。 引用[2]和[3]提供了解决方法:需要手动下载配置文件并修改,特别是针对离线安装或网络配置调整。 解决方案分步骤: 步骤1:手动下载 Calico 的两个配置文件并修改 步骤2:解决 CRD 注释过长问题(通过删除注释或使用更简化的版本) 步骤3:确保资源定义与 Kubernetes 版本兼容(v1.28.15 应支持 Calico v3.26.1) 具体操作: ### 1. 下载配置文件并修改 由于直接 apply 远程文件会导致 CRD 元数据注释过长,我们需要先下载文件,删除不必要的注释(特别是`kubectl.kubernetes.io/last-applied-configuration`)再应用。 ```bash # 下载 tigera-operator.yaml curl -O -L https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml # 下载 custom-resources.yaml curl -O -L https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/custom-resources.yaml ``` ### 2. 修改 tigera-operator.yaml 以解决注释过长问题 使用文本编辑器删除文件中所有不必要的注释(尤其是metadata.annotations部分)。重点删除`kubectl.kubernetes.io/last-applied-configuration`这个annotation,因为它可能很长。 示例:使用 `sed` 命令删除注释(或者手动编辑) ```bash # 删除 tigera-operator.yaml 中的 metadata.annotations 字段 # 注意:这里我们只删除metadata.annotations,而不是整个metadata # 由于yaml结构复杂,建议手动编辑或使用yq工具 # 如果没有yq,可以使用sed尝试(注意:可能不完美,建议手动检查) sed -i '/metadata:/,/spec:/{/annotations:/,/^[[:space:]]*[^[:space:]:]\+:/d}' tigera-operator.yaml # 解释:这个sed命令删除从'metadata:'开始到'spec:'之间的包含'annotations:'的行直到下一个非空且非缩进字段(即metadata块结束)。但为了安全,建议手动编辑。 ``` 手动编辑方法: - 打开 `tigera-operator.yaml` - 找到 `CustomResourceDefinition` 资源,其名称为 `installations.operator.tigera.io` - 删除整个 `metadata.annotations` 字段(包括该字段下的所有内容) ### 3. 检查并修改 custom-resources.yaml 根据引用[2],需要确保IP池配置正确(单机版通常无需修改,但若需修改网络CIDR,可在此调整)。同时,确保资源类型与API版本匹配。 在 `custom-resources.yaml` 中,确保 `apiVersion` 和 `kind` 正确: ```yaml apiVersion: operator.tigera.io/v1 kind: Installation ``` 注意:Kubernetes v1.28.15 应该支持 `operator.tigera.io/v1`。 ### 4. 应用修改后的文件 ```bash kubectl apply -f tigera-operator.yaml kubectl apply -f custom-resources.yaml ``` ### 5. 验证安装 等待片刻,检查Calico的Pod是否正常运行: ```bash kubectl get pods -n calico-system ``` ### 备选方案:使用更低版本的Calico 如果上述方法仍无法解决,可尝试使用更兼容的Calico版本(例如v3.25.1),步骤同上,只需修改下载链接中的版本号。 参考引用[3],离线环境下可能需要预先下载镜像,但单机在线安装通常不需要。 注意事项: - 如果集群中之前尝试安装过Calico,需先清理残留资源(`kubectl delete -f ...` 之前应用的配置文件,或直接删除命名空间 `kubectl delete namespace calico-system`) - 确保节点名称正确(`kubectl get nodes` 显示的节点名称)且网络无冲突。 ### 错误2:找不到 "Installation" 资源类型的匹配版本 这个错误通常是因为 `tigera-operator` 没有成功安装其CRD(即第一步的CRD应用失败)。因此,重点确保第一步的CRD(在tigera-operator.yaml中)成功创建。 检查CRD是否安装: ```bash kubectl get crd installations.operator.tigera.io ``` 如果不存在,则第一步的CRD应用失败,需要解决注释过长问题后重新应用。 如果存在,则可能是custom-resources.yaml中的apiVersion或kind拼写错误,请仔细核对。 根据引用[2]和[3],确保配置正确。 通过以上步骤,应能解决这两个错误。 §§相关问题§§ 1. 如何彻底卸载Calico以便重新安装? 2. 如何修改Calico的IP池配置以适配现有网络? 3. 如何确认Kubernetes版本与Calico版本的兼容性? </think>针对您在 Kubernetes v1.28.15 单机版安装 Calico v3.26.1 时遇到的元数据注释过长和资源类型不匹配问题,以下是完整解决方案: --- ### 问题原因分析 1. **元数据注释过长** 由于 Calico 的 CRD 定义包含过长的 `kubectl.kubernetes.io/last-applied-configuration` 注解字段,超过 Kubernetes 的 262144 字节限制[^1]。 2. **资源类型不匹配** Kubernetes v1.28 默认启用 API 版本 `operator.tigera.io/v1`,但旧版配置可能错误引用 `v1beta1` 等已弃用 API[^2]。 --- ### 解决方案分步指南 #### 步骤 1:清理残留配置 ```bash kubectl delete -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml --ignore-not-found kubectl delete crd installations.operator.tigera.io --ignore-not-found ``` #### 步骤 2:修复配置文件 1. **下载配置文件**: ```bash curl -O https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml curl -O https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/custom-resources.yaml ``` 2. **修改 `tigera-operator.yaml`**: 删除触发长度问题的注解: ```yaml # 在文本编辑器中打开 tigera-operator.yaml # 定位到 metadata.annotations 字段并删除以下两行: kubectl.kubernetes.io/last-applied-configuration: '...' # 删除此行 annotations: # 删除此行 ``` 3. **修改 `custom-resources.yaml`**: 确认 API 版本兼容性: ```yaml apiVersion: operator.tigera.io/v1 # 必须为 v1[^2] kind: Installation spec: calicoNetwork: ipPools: - cidr: 10.244.0.0/16 # 需与 kube-proxy 配置匹配 encapsulation: VXLANCrossSubnet # 推荐模式 natOutgoing: Enabled ``` #### 步骤 3:应用修复后的配置 ```bash kubectl apply -f tigera-operator.yaml kubectl apply -f custom-resources.yaml ``` #### 步骤 4:验证安装 ```bash watch kubectl get pods -n calico-system # 预期输出(2分钟内应全部Running): # NAME READY STATUS RESTARTS AGE # calico-node-xxxxx 1/1 Running 0 1m # calico-typha-xxxx 1/1 Running 0 1m ``` --- ### 关键配置注意事项 1. **网络 CIDR 一致性** 确保 `custom-resources.yaml` 中的 CIDR (`10.244.0.0/16`) 与 kube-proxy 配置匹配: ```bash grep -i cluster-cidr /etc/kubernetes/manifests/kube-proxy.yaml ``` 2. **kube-proxy 模式切换** 若使用 IPIP 模式,必须切换 kube-proxy 为 ipvs: ```yaml # 编辑 /etc/kubernetes/manifests/kube-proxy.yaml spec: containers: - command: - kube-proxy - --proxy-mode=ipvs # 添加此参数[^2] ``` 3. **节点污点处理** 单节点需解除调度限制: ```bash kubectl taint nodes rack-server node-role.kubernetes.io/control-plane:NoSchedule- ``` --- ### 故障排查技巧 - **检查 CRD 状态**: ```bash kubectl get crd installations.operator.tigera.io -o yaml # 正常状态应显示 established: true ``` - **日志诊断**: ```bash kubectl logs -n calico-system -l k8s-app=calico-node ``` - **API 版本验证**: ```bash kubectl api-resources | grep tigera.io # 应返回 operator.tigera.io/v1 资源 ``` > 注:若仍失败,可尝试兼容版本 Calico v3.27.3(下载链接见引用[^3])。 --- ### 验证网络功能 ```bash kubectl run test --image=nginx --restart=Never kubectl expose pod test --port=80 kubectl run checker --image=busybox --rm -it --restart=Never -- \ wget -O- test:80 # 成功应返回 Nginx 欢迎页 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值