首页 文章 精选 留言 我的

精选列表

搜索[AI原生]，共10000篇文章
优秀的个人博客,低调大师

每日一博 | 云原生 Kubernetes（k8s）标签详解

文章目录 前言 一、什么是Kubernetes标签 二、设计标签的目的 三、标签的语法 四、标签选择运算符 五、标签的使用 前言 我们知道使用pod控制器创建的pod，在pod故障以后重建后的pod ip地址和名称是变化的，为了解决pod访问问题，我们特此创建了service，我们访问service的ip地址就可以正常访问到pod；那么问题来了，service是怎样去关联pod的呢？在k8s上如果使用pod控制创建的pod，在pod发生故障以后，对应pod会被对应的控制器重启或重建，一个pod重建以后，对应的ip地址和名称都是会发生变化的，所以靠ip地址和名称关联pod是不行的；那靠什么关联pod呢？在k8s上是使用的标签和标签选择器的机制实现资源和资源间相互关联的。 什么是标签？它的作用是干嘛用的？ 所谓标签就是指一个键值数据，在k8s上任何资源都可以拥有标签；我们可以在创建资源时在配置清单中指定，也可以创建好资源以后再使用命令添加标签；有了标签以后，我们后续就可以根据标签来管理对应的资源；一个资源可以拥有多个标签，同时一个标签也可以附加给多个资源；我们可以理解为标签就是用来逻辑的对资源进行分组，拥有相同标签的资源为一组；标签的作用是方便用户管理资源；比如在k8s上运行了几百个pod，我们想要管理功能相同的pod，就可以把具有相似功能的pod附加同一个标签，然后要管理这些pod的时，直接指定拥有指定标签的pod即可。 一、什么是Kubernetes标签 要学习 k8s 标签，需要从以下几个方面来学习。 首先，我们需要知道什么是 k8s 标签。 在 k8s 中，标签（Labels）是附加到 k8s 对象（比如 Pods）上的键值对。 标签的一个示例如下所示： “metadata”:{ “labels”:{ “key1” : ”value1” “key2” : ”value2” } } 标签的作用主要有两点： 一是标签旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。 二是标签可以用于组织和选择对象的子集。 标签的特点主要有如下三点： 1、每个对象都可以定义一组键值标签。 2、每个键对于给定对象必须是唯一的。 3、标签能够支持高效的查询和监听操作，对于用户界面和命令行是很理想的。 二、设计标签的目的 设计标签的主要目的是使用户能够以松耦合的方式将他们自己的组织结构映射到系统对象，而无需客户端存储这些映射。 有如下几个示例标签,例如： 1、在区分发行版本的时候，可以指定: “release” : “canary” “release” : “dev” “release” : “beta” “release” : “stable” …… 2、在定义运行环境时，可以指定： “environment”: “dev” “environment”: “qa” “environment”: “production” …… 三、标签的语法 接着，我们来学习下标签的语法。 1、前缀： 1)前缀是可选的； 2)如果指定，前缀必须是DNS子域：由点“.”分割的一系列DNS标签，总共不超过253个字符，后跟斜杠“/”； 3)如果省略前缀，则假定标签键对用户是私有的。向最终用户对象添加标签的自动系统组件（例如：kube-scheduler、kube-controller-manager、kube-apiserver、kubctl或其他第三方自动化工具）必须指定前缀 2、名称： 1)名称段是必需的 2)必须小于等于63个字符，以字母数字字符“[a-z0-9A-Z]”开头和结尾，带有破折号“—”，下划线“_”，点“.”和之前的字母数字 3、小结：有效的标签值 1)必须为63个字符或更少（可以为空）； 2)除非标签值为空，必须以字母数字字符“[a-z0-9A-Z]”开头和结尾； 3)包含破折号“—”，下划线“_”，点“.”和之前的字母数字 示例：是一个有 environment 为 qa，同时 app 为 nginx 标签的 pod 配置文件。 apiVersion:v1 kind:Pod metadata: name:label-demo labels: environment:production app:nginx spec: containers: -name:nginx Image:nginx:1.14.2 Ports: -containerPort:80 四、标签选择运算符 然后，我们来学习下标签选择运算符。 标签选择运算符分为两种： 一种是基于等值的需求： 基于等值或基于不等值的需求允许按标签键和值进行过滤。 可接受的运算符有“=”、“==”、“！=”。 一种是基于集合的需求： 基于集合的标签需求允许你通过一组值来过滤键。 持有三种操作符：“in”、“notin”、“exists”。 最后，我们来学习下如何使用 API 来使用标签。 前面提到的两种标签选择算符都可以通过 REST 客户端用于 list 或者 watch 资源。 基于等值的需求可以使用如下命令来获取 pods。 Kubectl get pods –l environment-production,tier=frontend 基于集合的需求可以使用如下命令来获取 pods。 Kubectl get pods –l ‘environment in (production),tier in (frontend)’ 五、标签的使用 K8S中资源标签label 1、说明 标签label: 资源标志 格式 key=value 可添加删除多个标签 标签选择器 label selector: 用于选择资源 name=name1 name!=name1 name in (name1,name2) name not in (name1,name2) 2、指令 1）帮助： kubectl label --help 2）打标签： pod：kubectl label pods busybox app=busybox node：kubectl label node k8s-node01 k8s-node02 env=test 3）查看： 查看pods为busybox的标签： kubectl get pods busybox --show-labels 查看默认名称空间下所有pod资源的标签： kubectl get pods --show-labels 查看指定名称空间： kubectl get pods -n kube-system --show-labels 4）更新： 加上–overwrite参数修改标签 kubectl label po busybox app=busybox2 -n kube-public --overwrite 5）通过标签筛选： 列出默认名称空间下标签key是app的pod，不显示标签： kubectl get pods -l app 列出默认名称空间下标签key是app、值是busybox的pod，不显示标签： kubectl get pods -l app=busybox 多个筛选条件： kubectl get po -l version!=v1,app=nginx 6）删除： pod：kubectl label po busybox app- -n kube-public node：kubectl label node k8s-node02 env- 3、配置 1）创建label-nginx.yaml apiVersion: v1 kind: Pod metadata: name: nginx namespace: dev labels: version: "1.0.0" env: "test" spec: containers: - image: nginx imagePullPolicy: IfNotPresent name: pod ports: - name: nginx-port containerPort: 80 protocol: TCP 2）创建 kubectl create -f label-nginx.yaml 3）删除 kubectl delete -f label-nginx.yaml 以上就是K8s 标签的介绍。
2022-09-05
优秀的个人博客,低调大师

bali 3.2.0 发布：云原生 Python 框架带来的重大变化

更新内容： 新增 引入manager概念🥂 新的优雅的 API 定义🥂PR#122 增加db.Basedeclarative_base 应用增加__clear__方法，方便单元测试 为注册的 Resource 生成 gRPC 服务类🍕PR#125 引入pytest-grpc作为 gRPC 单元测试组件 调整 移除connection.retry_on_deadlock_decorator 移除connection.close_connection 移除bali.schema, 用bali.schemas替代 标识GRPCTestBase废弃, 并将于 v3.5 移除 增加更多的单元测试保证软件质量 🏄‍ 修复 修复请求及项目的初始问题 修复 ModelResource 在注册模式下的问题 -- 让我们来详解一下几个比较大的变化点吧： Model 新增 manager 概念 相信 Django 是很多 Pythonista 的入门框架，Django 的 Model 里面的文档 advanced 部分有关于 manager 的介绍，https://docs.djangoproject.com/en/4.0/topics/db/managers/。Bali 3.2 引入的 manager 概念与 Django 里面的 manager 概念非常相似，只不过调用方式不同。 # Sync user = User.io.first() # Async user = await User.aio.first() Model 新增优雅的异步 API 方案 近些年大部分的语言都拥有了完善的异步 IO 方案，从早期的 JavaScript 里面的 defer、 promise，到 Java 里面的 Netty，Go 里面的 Goroutine。不管哪个方案，都没有 Python 里面这么纠结的就是同步和异步是同时需要提供的。像 JavaScript 的 promise，内置的网络请求返回的总是 promise 对象，你只能用异步 IO 的思维去处理。 还未发布的 Django 4.1 已经在 Model 层增加了异步方法，API 如下： Person.objects.acreate(first_name="Bruce", last_name="Springsteen") Person.objects.afirst(first_name="Bruce", last_name="Springsteen") 可以看到，Django 的 QuerySet 及 Manager 对异步的支持是在原有的单词上增加了 `a`，个人觉得这样让代码可读性及语义化受到了干扰，create 一眼就知道是创建的意思，`acreate`是什么，如果我熟悉 Django，我会猜到这是异步的调用方式，是一个 awatable 的函数。如果业务里面需要自定义一个函数呢，比如 choose_best，这时按 Django 的方案就是 achoose_best 表示异步 IO 的方式。可以看出，choose 并不像 get、create 这么常见的时候，achoose 让我们产生了疑问，单词拼写错误？看 PyCharm 已经用波浪线提示拼写错误了。 Bali 里采用的 API 方案是 Query 使用 io/aio 来区分同步和异步，而对于 Model，自动根据当前的上下文来自适应，看一下使用示例： 使用 Manager 时 # sync user = User.io.create(username=username) # async user = await User.aio.create(username=username) 使用 Model 的实例时 异步示例： async with db.async_session() as session: result = await session.execute( select(User).where(User.username == username) ) user = result.scalars().first() # 由于 user 是在 async_session 的 context 里面查询出来的 # 所以 user 的自带的实例方法(save, delete 等)都自动转换成了异步方法 await user.save() 同步示例： user = User(username=username) user.save() 简化的注册 Resource 的方式 3.2 版本引入了 Resource 的注册使用方式，为了配合这个方式，Bali 将 Application 进行了大量重构及优化。这样一来，main.py 启动入口的代码得到了极大程度的精简。我们看一下对比： 之前版本需要将 HTTP 服务的 routers 及 RPC 服务的 service 分别传入，3.2 的版本只需要指定 title 及注册 Resource 就可以了。对应的 routers 及 service 会在启动时自动去动态生成。 我们再来看一下 Resource 转成 HTTP 服务的方式变化： 之前需要手动在 urls.py 里面手动注册，3.2 将 resource 注册到 app 后，路由相关的文件全部可以移除，是一个可选项。当然旧项目升级时，完全不受影响，因为原来的方案也注册的方式兼容，同时使用原来的定义方案及注册的方式也是可以正常的。 gRPC 的服务文件的极度简化 为什么说是极度简化呢，因为原来的 gRPC 的文件 services/rpc/service.py 这个文件直接可以移除了。 gRPC 的服务文件的极度简化 项目结构 layout structure 的变化对比： 除了 core、logic、biz 等概念，services 也从固定的结构被成了灵活结构，关键是整个 services 都是可选的。如果所有的业务都使用 Resource 开发，将没有 services 文件夹。
2022-06-17
优秀的个人博客,低调大师

分布式云原生数据库中的共识流程

Raft Scheduler概述 Raft Scheduler在节点初始化时会一起启动，同时还会一同启动raftTickLoop进程用于定时产生tick请求。 Raft Scheduler主要的功能是处理raftGroup内部的消息请求与外部的写入读取请求，Raft Scheduler的工作方式是通过对外提供一个rangeID队列，当有请求来时，会修改该请求设计的range状态，并将其放入这个队列中，同时当Raft Scheduler跟随云溪数据库启动而初始化时，会初始化一定数量的processor，这些processor的作用是监听消息队列，当消息队列中有rangeID入队时，processor会将该rangeID取出，并根据该rangeID入队时的状态(stateTick、stateReady、stateRequest)进行不同处理。 我们在后续优化云溪数据库版本的过程中将RaftScheduler额外划分了一部分资源用于处理tick请求从而降低心跳延迟，这并不影响我们理解整体的逻辑处理流程。 Request入队流程 在副本层中需要处理的数据来自于分发层通过gRPC发送来的RaftMessageBatch，以及内部产生的消息请求。 当接收到分发层的RaftMessageBatch后，消息处理会通过store获取RaftMessageRequest对应rangeID的raftRequestQueue，并将RaftMessageRequest转换成raftRequestInfo追加至raftRequestQueue中。与此同时，更新rangeID对应的raftScheduleState并将rangeID添加到raftScheduler的queue中等待raft processor调度处理。 StateRaftTick处理流程 如果processor从rangeIDQueue中取出的rangeID对应状态为stateRaftTick，则processor会调用ProcessTick()方法进行处理。 首先，processor会在store中获取该rangeID的本地replica和对应livenessMap, 然后调用replica_raft.go下tick()。获取replica的unreachable remotes，构造MsgUnreachable, 通过replica所在的raft group处理该msg。结束这一步后，会验证replica是否为静默状态，如果replica是静默状态，则无需tick。Tick的条件为： raft group已初始化。 replica是非静默的。 再次检查replica是否静默，静默的判断条件为满足以下所有条件： 1. cluster启用静默配置。 2. replica不存在尚未应用的raft command。 3. replica不存在进行中的merge。 4. replica没有被destroyed。 5. replica所在raft group状态非空。 6. replica是raft leader。 7. replica当前不存在raft leader切换。 8. replica是leaseholder。 9. raft的applied/commit/lastindex相等。 10. 获取所有remote replica，除了不在livenessMap中的node，remote replica在leader生成的progress列表中，同时remote replica的progress match值必须跟当前raft的applied相等。 11. replica本身必须在progress列表中。 12. raft当前状态不是ready。 如果判断当前replica所在raft group是静默状态，只发送心跳数据: 首先，获取range中其他remote replica的ReplicaDescriptor，为每个remote replica构造raftpb.MsgHeartbeat,构造StoreIdent和RaftHeartbeat,生成KV并写入store的heartbeats map<目标store标识，心跳数据>中，在store.go->coalescedHeartbeatsLoop()处理store的心跳数据，对每个KV构造RaftMessageRequest并写入对应节点的channel中，在raft_transport.go->startProcessNewQueue()->processQueue()中维护该channel，负责将request转发到指定replica。 如果判断当前replica所在raft group是非静默状态，除进行上述操作外，在这之后会检查当前replica是否同时为raft leader和leaseholder(DisableLeaderFollowsLeaseholder为false时的要求)，如果不满足，会构造leader切换的message，发起一轮选举。 - StateRaftReady - 如果rangeID对应的状态是stateRaftReady。 1. store.go->processReady()首先从store中获取该rangeID对应的本地replica，通过relica的internalRaftGroup构造raft Ready数据(raft Ready包含了需要持久化的entries和需要提交或发送到其他节点的message)，然后将Ready中包含的msg分为MsgApp和其他类型两部分，首先将MsgApp类型消息构造成RaftMessageRequest写入到对应node的channel中，然后通过raft_transport.go->startProcessNewQueue()->processQueue()转发到指定replica。 2. 在异步发送msg过程中，会通过rocksDB/Pebble构造batch，同时处理Ready中包含的待持久化的entries，并构造repr，然后使用构造的batch将repr异步迭代写入到store对应的存储引擎中。 3. 将拆分出的其他消息类型构造RaftMessageRequest发送到node的channel中。 4. 从Ready中包含的CommittedEntries每一行中获取command id和raft command并生成WriteBatch,构造WriteBatch, 并生成Repr，将Repr中数据异步落盘。 - StateRaftRequest - 如果rangeID对应的状态是stateRaftRequest，从store中获取该rangeID对应的raftRequestQueue，然后获取队列中的每个raftRequestInfo,每个raftRequestInfo中的RaftMessageRequest都带有一条message，根据每条message的type不同有不同的处理方法，可参考上述Msg类型篇。 1. MsgHub，当follower节点的选举计时器超时后，会发送msgHub. 2. MsgBeat，leader发送的心跳信息，心跳计时器超时时触发该消息，leader通过stepLeader()生成MsgHeartbeat发送给集群中其他节点。 3. MsgProp，客户端向集群发送的写请求通过msgProp表示。 4. MsgApp，当一个节点通过选举成为leader后，会获取目标节点Next-1对应的记录的term值和需要发送的Entries,然后发送MsgApp消息，该消息可以帮助follower节点与leader节点同步。 5. MsgAppResp，msgApp的响应消息类型，当follower节点收到msgApp后，无论是否进行日志追加，都将返回一条带有本节点最后一条记录索引值的消息。 6. MsgVote，当PreCandidate状态节点收到半数以上的投票之后，会发起新一轮的选举，即向集群中的其他节点发送MsgVote。 7. MsgVoteResp，msgVote的响应消息。 8. MsgSnap，当leader获取目标节点Next-1对应的记录的term值和需要发送的Entries出现异常时，就会生成msgSnap将快照数据发送到follower节点，follower节点通过快照数据恢复状态，从而可以与leader进行正常的entry记录复制。 9. MsgHeartbeat，leader发送的心跳消息，主要作用是探测节点是否存活，follower接收到msgHeartbeat会重置自身的选举计时器，防止follower发起新一轮的选举。同时尝试更新follower节点raftLog中已提交的位置。 10. MsgHeartbeatResp，follower处理心跳消息返回的消息类型。 11. MsgUnreachable，如果leader发送MsgSnap消息出现异常，将会调用ReportUnreachable()发送该类型消息，将follower节点的状态改为ProgressStateProbe。 12. MsgSnapStatus，校验节点对应的状态是否为ProgressStateSnapshot，如果之前发送的快照消息出现异常则将节点状态改为ProgressStateProbe，之后单条发送消息。 13. MsgCheckQuorum，leader发送该消息类型检测是否保持半数以上连接。当Leader 的心跳计时器超时，并且开启了checkQuorum模式(raft的checkQuorum字段为true)。该Leader节点就会发送MsgCheckQuorum消息检测与集群中其他节点是否保持半数以上的连接，如果没有则变成Follower节点。 14. MsgTransferLeader，发起leader节点转移的消息类型，本地消息。 15. MsgTimeoutNow，如果leader节点转移超时，会发送该类型的消息，使follower的选举计时器立即过期，并发起新一轮的选举。 16. MsgReadIndex，客户端发往集群的只读消息使用该类型。 17. MsgReadIndexResp，只读消息类型的响应消息。 18. MsgPreVote，当Follower的选举计时器超时时，会把当前状态切换成 StatePreCandidate（预选举），并向集群中其他节点发送MsgPreVote。当集群中其他节点收到预选举消息时，会先进行一些检验，符合相关条件会投同意，否则会投拒绝票，然后发送给该候选节点，发送的消息类型为MsgPreVoteResp。如果预选举阶段(StatePreCandidate)成功收到超过半数以上的同意票，那么该节点会认为选举成功，会发起新一轮的正式选举(节点状态切换成SateCandidate(候选人)，发送的消息类型为MsgVote)。是否有预选举阶段是根据初始化配置的参数,该字段保存在raft结构体的preVote字段中 19. MsgPreVoteResp，其他节点响应预选举的投票消息。
2022-06-15

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-04-11 大小: 211.28KB 下载: 56次
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-24 大小: 189MB 下载: 9次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册