K8S系列一:概念入门

在这里插入图片描述

写在前面

本文组织方式:

  1. K8S的架构、作用和目的。需要首先对K8S整体有所了解。
    K8S是什么?
    为什么是K8S?
    K8S怎么做?

  2. K8S的重要概念,即K8S的API对象。要学习和使用K8S必须知道和掌握的几个对象。
    Pod 实例
    Volume 数据卷
    Container 容器
    Deployment 和 ReplicaSet
    Service和Ingress
    namespace 命名空间
    其他

I. K8S概览

1.1 K8S是什么?

K8S是Kubernetes的全称,官方称其是:

Kubernetes is an open source system for managing containerized applications across multiple hosts. It provides basic mechanisms for deployment, maintenance, and scaling of applications.
用于自动部署、扩展和管理“容器化(containerized)应用程序”的开源系统。

翻译成大白话就是:“K8S是负责自动化运维管理多个Docker程序的集群”。 那么问题来了:Docker运行可方便了,为什么要用K8S,它有什么优势?
插一句题外话:

  • 为什么Kubernetes要叫Kubernetes呢?维基百科已经交代了(老美对星际是真的痴迷):
    Kubernetes(在希腊语意为“舵手”或“驾驶员”)由Joe Beda、Brendan Burns和Craig
    McLuckie创立,并由其他谷歌工程师,包括Brian Grant和Tim Hockin等进行加盟创作,并由谷歌在2014年首次对外宣布
    。该系统的开发和设计都深受谷歌的Borg系统的影响,其许多顶级贡献者之前也是Borg系统的开发者。在谷歌内部,Kubernetes的原始代号曾经是Seven,即星际迷航中的Borg(博格人)。Kubernetes标识中舵轮有七个轮辐就是对该项目代号的致意。
  • 为什么Kubernetes的缩写是K8S呢?我个人赞同Why Kubernetes is Abbreviated
    k8s中说的观点“嘛,写全称也太累了吧,不如整个缩写”。其实只保留首位字符,用具体数字来替代省略的字符个数的做法,还是比较常见的。

1.2 为什么是K8S?

试想下传统的后端部署办法:把程序包(包括可执行二进制文件、配置文件等)放到服务器上,接着运行启动脚本把程序跑起来,同时启动守护脚本定期检查程序运行状态、必要的话重新拉起程序。

有问题吗?显然有!最大的一个问题在于:如果服务的请求量上来,已部署的服务响应不过来怎么办? 传统的做法往往是,如果请求量、内存、CPU超过阈值做了告警,运维马上再加几台服务器,部署好服务之后,接入负载均衡来分担已有服务的压力。

问题出现了:从监控告警到部署服务,中间需要人力介入!那么,有没有办法自动完成服务的部署、更新、卸载和扩容、缩容呢?

这,就是K8S要做的事情:自动化运维管理Docker(容器化)程序。

1.3 K8S怎么做?

我们已经知道了K8S的核心功能:自动化运维管理多个容器化程序。那么K8S怎么做到的呢?这里,我们从宏观架构上来学习K8S的设计思想。首先看下图,图片来自文章Components of Kubernetes Architecture:
在这里插入图片描述
K8S是属于主从设备模型(Master-Slave架构),即有Master节点负责核心的调度、管理和运维,Slave节点则在执行用户的程序。但是在K8S中,主节点一般被称为Master Node或者Head Node(本文采用Master Node称呼方式),而从节点则被称为Worker Node或者Node(本文采用Worker Node称呼方式)。

要注意一点:Master Node和Worker Node是分别安装了K8S的Master和Woker组件的实体服务器,每个Node都对应了一台实体服务器(虽然Master Node可以和其中一个Worker Node安装在同一台服务器,但是建议Master Node单独部署),所有Master Node和Worker Node组成了K8S集群,同一个集群可能存在多个Master Node和Worker Node。

首先来看Master Node都有哪些组件:

  • API Server。K8S的请求入口服务。API Server负责接收K8S所有请求(来自UI界面或者CLI命令行工具),然后,API
    Server根据用户的具体请求,去通知其他组件干活。
  • Scheduler。K8S所有Worker Node的调度器。当用户要部署服务时,Scheduler会选择最合适的Worker Node(服务器)来部署。
  • Controller Manager。K8S所有Worker Node的监控器。Controller Manager有很多具体的Controller,在文章Components of Kubernetes Architecture中提到的有Node Controller、Service Controller、Volume Controller等。Controller负责监控和调整在Worker Node上部署的服务的状态,比如用户要求A服务部署2个副本,那么当其中一个服务挂了的时候,Controller会马上调整,让Scheduler再选择一个Worker Node重新部署服务。
  • etcd。K8S的存储服务。etcd存储了K8S的关键配置和用户配置,K8S中仅API Server才具备读写权限,其他组件必须通过API
    Server的接口才能读写数据(见Kubernetes Works Like an Operating System)。

接着来看Worker Node的组件,笔者更赞同HOW DO APPLICATIONS RUN ON KUBERNETES文章中提到的组件介绍:

  • Kubelet。Worker Node的监视器,以及与Master Node的通讯器。Kubelet是Master
    Node安插在Worker Node上的“眼线”,它会定期向Worker
    Node汇报自己Node上运行的服务的状态,并接受来自Master Node的指示采取调整措施。
  • Kube-Proxy。K8S的网络代理。私以为称呼为Network-Proxy可能更适合?Kube-Proxy负责Node在K8S的网络通讯、以及对外部网络流量的负载均衡。
  • Container Runtime。Worker Node的运行环境。即安装了容器化所需的软件环境确保容器化程序能够跑起来,比如Docker Engine。大白话就是帮忙装好了Docker运行环境。
  • Logging Layer。K8S的监控状态收集器。私以为称呼为Monitor可能更合适?Logging
    Layer负责采集Node上所有服务的CPU、内存、磁盘、网络等监控项信息。
  • Add-Ons。K8S管理运维Worker Node的插件组件。有些文章认为Worker
    Node只有三大组件,不包含Add-On,但笔者认为K8S系统提供了Add-On机制,让用户可以扩展更多定制化功能,是很不错的亮点。

总结来看,K8S的Master Node具备:请求入口管理(API Server),Worker Node调度(Scheduler),监控和自动调节(Controller Manager),以及存储功能(etcd);而K8S的Worker Node具备:状态和监控收集(Kubelet),网络和负载均衡(Kube-Proxy)、保障容器化运行环境(Container Runtime)、以及定制化功能(Add-Ons)

II. K8S重要概念

2.1 Pod实例

官方对于Pod的解释是:

Pod是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

这样的解释还是很难让人明白究竟Pod是什么,但是对于K8S而言,Pod可以说是所有对象中最重要的概念了!因此,我们必须首先清楚地知道“Pod是什么”,再去了解其他的对象。

从官方给出的定义,联想下“最小的xxx单元”,是不是可以想到本科在学校里学习“进程”的时候,教科书上有一段类似的描述:资源分配的最小单位;还有”线程“的描述是:CPU调度的最小单位。什么意思呢?”最小xx单位“要么就是事物的衡量标准单位,要么就是资源的闭包、集合。前者比如长度米、时间秒;后者比如一个”进程“是存储和计算的闭包,一个”线程“是CPU资源(包括寄存器、ALU等)的闭包。

同样的,Pod就是K8S中一个服务的闭包。这么说的好像还是有点玄乎,更加云里雾里了。简单来说,Pod可以被理解成一群可以共享网络、存储和计算资源的容器化服务的集合。再打个形象的比喻,在同一个Pod里的几个Docker服务/程序,好像被部署在同一台机器上,可以通过localhost互相访问,并且可以共用Pod里的存储资源(这里是指Docker可以挂载Pod内的数据卷,数据卷的概念,后文会详细讲述,暂时理解为“需要手动mount的磁盘”)。笔者总结Pod如下图,可以看到:同一个Pod之间的Container可以通过localhost互相访问,并且可以挂载Pod内所有的数据卷;但是不同的Pod之间的Container不能用localhost访问,也不能挂载其他Pod的数据卷
在这里插入图片描述

对Pod有直观的认识之后,接着来看K8S中Pod究竟长什么样子,具体包括哪些资源?

K8S中所有的对象都通过yaml来表示,笔者从官方网站摘录了一个最简单的Pod的yaml:

apiVersion: v1
kind: Pod
metadata:name: memory-demonamespace: mem-example
spec:containers:- name: memory-demo-ctrimage: polinux/stressresources:limits:memory: "200Mi"requests:memory: "100Mi"command: ["stress"]args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]volumeMounts:- name: redis-storagemountPath: /data/redisvolumes:- name: redis-storageemptyDir: {}

看不懂不必慌张,且耐心听下面的解释:

  • apiVersion记录K8S的API Server版本,现在看到的都是v1,用户不用管。
  • kind记录该yaml的对象,比如这是一份Pod的yaml配置文件,那么值内容就是Pod。
  • metadata记录了Pod自身的元数据,比如这个Pod的名字、这个Pod属于哪个namespace(命名空间的概念,后文会详述,暂时理解为“同一个命名空间内的对象互相可见”)。
  • spec记录了Pod内部所有的资源的详细信息,看懂这个很重要:
  • containers记录了Pod内的容器信息,containers包括了:name容器名,image容器的镜像地址,resources容器需要的CPU、内存、GPU等资源,command容器的入口命令,args容器的入口参数,volumeMounts容器要挂载的Pod数据卷等。可以看到,上述这些信息都是启动容器的必要和必需的信息。
  • volumes记录了Pod内的数据卷信息,后文会详细介绍Pod的数据卷。

2.2 Volume 数据卷

K8S支持很多类型的volume数据卷挂载,具体请参见K8S卷。前文就“如何理解volume”提到:“需要手动mount的磁盘”,此外,有一点可以帮助理解:数据卷volume是Pod内部的磁盘资源。

其实,单单就Volume来说,不难理解。但是上面还看到了volumeMounts,这俩是什么关系呢?

volume是K8S的对象,对应一个实体的数据卷;而volumeMounts只是container的挂载点,对应container的其中一个参数。但是,volumeMounts依赖于volume,只有当Pod内有volume资源的时候,该Pod内部的container才可能有volumeMounts。

2.3 Container 容器

本文中提到的镜像Image、容器Container,都指代了Pod下的一个container。关于K8S中的容器,在2.1Pod章节都已经交代了,这里无非再啰嗦一句:一个Pod内可以有多个容器container

在Pod中,容器也有分类,对这个感兴趣的同学欢迎自行资料:

  • 标准容器 Application Container
  • 初始化容器 Init Container
  • 边车容器 Sidecar Container
  • 临时容器 Ephemeral Container

一般来说,我们部署的大多是标准容器( Application Container)

2.4 Deployment 和 ReplicaSet(简称RS)

除了Pod之外,K8S中最常听到的另一个对象就是Deployment了。那么,什么是Deployment呢?官方给出了一个要命的解释:

一个 Deployment 控制器为 Pods 和 ReplicaSets 提供声明式的更新能力。 你负责描述 Deployment 中的
目标状态,而 Deployment 控制器以受控速率更改实际状态, 使其变为期望状态。你可以定义 Deployment 以创建新的
ReplicaSet,或删除现有 Deployment,并通过新的 Deployment 收养其资源。

翻译一下:Deployment的作用是管理和控制Pod和ReplicaSet,管控它们运行在用户期望的状态中。哎,打个形象的比喻,Deployment就是包工头,主要负责监督底下的工人Pod干活,确保每时每刻有用户要求数量的Pod在工作。如果一旦发现某个工人Pod不行了,就赶紧新拉一个Pod过来替换它。

新的问题又来了:那什么是ReplicaSets呢?

ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。 因此,它通常用来保证给定数量的、完全相同的
Pod 的可用性。

再来翻译下:ReplicaSet的作用就是管理和控制Pod,管控他们好好干活。但是,ReplicaSet受控于Deployment。形象来说,ReplicaSet就是总包工头手下的小包工头

笔者总结得到下面这幅图,希望能帮助理解:
在这里插入图片描述
新的问题又来了:如果都是为了管控Pod好好干活,为什么要设置Deployment和ReplicaSet两个层级呢,直接让Deployment来管理不可以吗?

回答:不清楚,但是私以为是因为先有ReplicaSet,但是使用中发现ReplicaSet不够满足要求,于是又整了一个Deployment(有清楚Deployment和ReplicaSet联系和区别的小伙伴欢迎留言啊)。

但是,从K8S使用者角度来看,用户会直接操作Deployment部署服务,而当Deployment被部署的时候,K8S会自动生成要求的ReplicaSet和Pod。在K8S官方文档中也指出用户只需要关心Deployment而不操心ReplicaSet:

This actually means that you may never need to manipulate ReplicaSet
objects: use a Deployment instead, and define your application in the
spec section.
这实际上意味着您可能永远不需要操作ReplicaSet对象:直接使用Deployments并在规范部分定义应用程序。

补充说明:在K8S中还有一个对象 — ReplicationController(简称RC),官方文档对它的定义是:

ReplicationController 确保在任何时候都有特定数量的 Pod 副本处于运行状态。
换句话说,ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的。

怎么样,和ReplicaSet是不是很相近?在Deployments, ReplicaSets, and pods教程中说“ReplicationController是ReplicaSet的前身”,官方也推荐用Deployment取代ReplicationController来部署服务。

2.5 Service和Ingress

吐槽下K8S的概念/对象/资源是真的多啊!前文介绍的Deployment、ReplicationController和ReplicaSet主要管控Pod程序服务;那么,Service和Ingress则负责管控Pod网络服务

我们先来看看官方文档中Service的定义:

将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。 使用 Kubernetes,您无需修改应用程序即可使用不熟悉的服务发现机制。
Kubernetes 为 Pods 提供自己的 IP 地址,并为一组 Pod 提供相同的 DNS 名, 并且可以在它们之间进行负载均衡。

翻译下:K8S中的服务(Service)并不是我们常说的“服务”的含义,而更像是网关层,是若干个Pod的流量入口、流量均衡器。
那么,为什么要Service呢?

私以为在这一点上,官方文档讲解地非常清楚:

Kubernetes Pod 是有生命周期的。 它们可以被创建,而且销毁之后不会再启动。 如果您使用 Deployment
来运行您的应用程序,则它可以动态创建和销毁 Pod。 每个 Pod 都有自己的 IP 地址,但是在 Deployment
中,在同一时刻运行的 Pod 集合可能与稍后运行该应用程序的 Pod 集合不同。 这导致了一个问题: 如果一组
Pod(称为“后端”)为群集内的其他 Pod(称为“前端”)提供功能, 那么前端如何找出并跟踪要连接的 IP
地址,以便前端可以使用工作量的后端部分?

补充说明:K8S集群的网络管理和拓扑也有特别的设计,以后会专门出一章节来详细介绍K8S中的网络。这里需要清楚一点:K8S集群内的每一个Pod都有自己的IP(是不是很类似一个Pod就是一台服务器,然而事实上是多个Pod存在于一台服务器上,只不过是K8S做了网络隔离),在K8S集群内部还有DNS等网络服务(一个K8S集群就如同管理了多区域的服务器,可以做复杂的网络拓扑)。

此外,笔者推荐k8s外网如何访问业务应用对于Service的介绍,不过对于新手而言,推荐阅读前半部分对于service的介绍即可,后半部分就太复杂了。我这里做了简单的总结:

Service是K8S服务的核心,屏蔽了服务细节,统一对外暴露服务接口,真正做到了“微服务”。举个例子,我们的一个服务A,部署了3个备份,也就是3个Pod;对于用户来说,只需要关注一个Service的入口就可以,而不需要操心究竟应该请求哪一个Pod。优势非常明显:一方面外部用户不需要感知因为Pod上服务的意外崩溃、K8S重新拉起Pod而造成的IP变更,外部用户也不需要感知因升级、变更服务带来的Pod替换而造成的IP变化,另一方面,Service还可以做流量负载均衡

但是,Service主要负责K8S集群内部的网络拓扑。那么集群外部怎么访问集群内部呢?这个时候就需要Ingress了,官方文档中的解释是:

Ingress 是对集群中服务的外部访问进行管理的 API 对象,典型的访问方式是 HTTP。 Ingress 可以提供负载均衡、SSL
终结和基于名称的虚拟托管。

翻译一下:Ingress是整个K8S集群的接入层,复杂集群内外通讯。

最后,笔者把Ingress和Service的关系绘制网络拓扑关系图如下,希望对理解这两个概念有所帮助:
在这里插入图片描述

2.6 namespace 命名空间

和前文介绍的所有的概念都不一样,namespace跟Pod没有直接关系,而是K8S另一个维度的对象。或者说,前文提到的概念都是为了服务Pod的,而namespace则是为了服务整个K8S集群的。

那么,namespace是什么呢?

上官方文档定义:

Kubernetes 支持多个虚拟集群,它们底层依赖于同一个物理集群。 这些虚拟集群被称为名字空间。

翻译一下:namespace是为了把一个K8S集群划分为若干个资源不可共享的虚拟集群而诞生的。

也就是说,可以通过在K8S集群内创建namespace来分隔资源和对象。比如我有2个业务A和B,那么我可以创建ns-a和ns-b分别部署业务A和B的服务,如在ns-a中部署了一个deployment,名字是hello,返回用户的是“hello a”;在ns-b中也部署了一个deployment,名字恰巧也是hello,返回用户的是“hello b”(要知道,在同一个namespace下deployment不能同名;但是不同namespace之间没有影响)。前文提到的所有对象,都是在namespace下的;当然,也有一些对象是不隶属于namespace的,而是在K8S集群内全局可见的,官方文档提到的可以通过命令来查看,具体命令的使用办法,笔者会出后续的实战文章来介绍,先贴下命令:

# 位于名字空间中的资源
kubectl api-resources --namespaced=true
​
# 不在名字空间中的资源
kubectl api-resources --namespaced=false

不在namespace下的对象有:
在这里插入图片描述
在namespace下的对象有(部分):
在这里插入图片描述

2.7 其他

K8S的对象实在太多了,2.1-2.6介绍的是在实际使用K8S部署服务最常见的。其他的还有Job、CronJob等等,在对K8S有了比较清楚的认知之后,再去学习更多的K8S对象,不是难事。

写在后面

本文是K8S系列文章第一篇,希望能够帮助对K8S不了解的新手快速了解K8S。如果文章中有纰漏,非常欢迎留言或者私信指出;有理解错误的地方,更是欢迎留言或者私信告知。

笔者一边写文章,一边查阅和整理K8S资料,过程中越发感觉K8S架构的完备、设计的精妙,是值得深入研究的,K8S大受欢迎是有道理的!再次感叹下。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/38638.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

php错误类型与处理

1 语法编译错误,少了分号,这是系统触发的错误,不需要我们去管。 2 错误类型有四种:error致命错误,代码不会往下运行;warning:提醒错误,会往下运行,但是会有意想不到的结果…

【C++学习】STL容器——stack和queue

目录 一、stack的介绍和使用 1.1 stack的介绍 1.2 stack的使用 1.3 stack的模拟实现 二、queue的介绍和使用 2.1 queue的介绍 2.2 queue的使用 2.3 queue的模拟实现 三、priority_queue的介绍和使用 3.1 priority_queue的介绍和使用 3.2 priority_queue的使用 3.4 p…

JVM---理解jvm之对象已死怎么判断?

目录 引用计数算法 什么是引用 可达性分析算法(用的最多的) 引用计数算法 定义:在对象中添加一个引用计数器,每当有一个地方引用它时,计数器值就加一;当引用失效时,计数器值就减一&#xff1…

国内外医疗器械政策法规网站集合

随着医疗技术的不断发展,医疗器械在现代医疗中扮演着重要的角色。为了确保医疗器械的安全性、有效性和质量,各国纷纷制定了一系列的政策法规来监管医疗器械的研发、生产、销售和使用。这些政策法规的制定和实施对于保障公众健康、促进医疗器械产业的健康…

旧版本docker未及时更新,导致更新/etc/docker/daemon.json配置文件出现docker重启失败

一、背景 安装完docker和containerd之后,尝试重启docker的时候,报错如下: systemctl restart dockerJob for docker.service failed because the control process exited with error code. See “systemctl status docker.service” and “…

学习ts(一)数据类型(基础类型和任意类型)

运行 起步安装 npm install typescript -g 运行tsc index.ts生成对应的js文件,然后使用node index.js执行js文件 为了方便运行还可以安装插件,ts-node index.ts运行即可 npm i ts-node -g npm init -y npm i types/node -D基本数据类型 // 1.字符…

ARM(汇编指令)

.global _start _start:/*mov r0,#0x5mov r1,#0x6 bl LoopLoop:cmp r0,r1beq stopsubhi r0,r0,r1subcc r1,r1,r0mov pc,lr*/ mov r0,#0x1mov r1,#0x0mov r2,#0x64bl Loop Loop:cmp r0,r2bhi stopadd r1,r1,r0add r0,r0,#0x01mov pc,lr stop:B stop.end

现有的vue3+ts+vite项目集成electron

效果图 什么时Electron Electron是使用JavaScript,HTML和CSS构建跨平台的桌面应用程序框架。 Electron兼容Mac、Windows和Linux,可以构建出三个平台的应用程序。 现有的vue3项目集成Electron 安装依赖 原来有一个vue3+ts+vite+pnpm的项目,其中sub-modules是子项目,web是…

Monge矩阵

Monge矩阵 对一个m*n的实数矩阵A&#xff0c;如果对所有i&#xff0c;j&#xff0c;k和l&#xff0c;1≤ i<k ≤ m和1≤ j<l ≤ n&#xff0c;有 A[i,j]A[k,l] ≤ A[i,l]A[k,j] 那么&#xff0c;此矩阵A为Monge矩阵。 换句话说&#xff0c;每当我们从矩阵中挑…

全面梳理Python下的NLP 库

一、说明 Python 对自然语言处理库有丰富的支持。从文本处理、标记化文本并确定其引理开始&#xff0c;到句法分析、解析文本并分配句法角色&#xff0c;再到语义处理&#xff0c;例如识别命名实体、情感分析和文档分类&#xff0c;一切都由至少一个库提供。那么&#xff0c;你…

地理数据的双重呈现:GIS与数据可视化

前一篇文章带大家了解了GIS与三维GIS的关系&#xff0c;本文就GIS话题带大家一起探讨一下GIS和数据可视化之间的关系。 GIS&#xff08;地理信息系统&#xff09;和数据可视化在地理信息科学领域扮演着重要的角色&#xff0c;它们之间密切相关且相互增强。GIS是一种用于采集、…

欧拉函数和最大公约数

分析&#xff1a;如果两个数的最大公约数是一个质数p&#xff0c;那么这两个数都除以p&#xff0c;得到的两个数的最大公约数一定是1. 反证法&#xff1a;如果得到的两个数的最大公约数不是1&#xff0c;那么把此时的最大公约数乘以上边的最大公约数&#xff0c;得到的一定比上…

文件操作 和 IO

目录 ​编辑一、认识文件 1、文件路径 2、其它知识 二、Java 中操作文件 三、文件内容的读写 1、Reader 2、InputStream 3、输出 一、认识文件 文件是在硬盘上存储数据的一种方式&#xff0c;操作系统帮我们把硬盘的一些细节都封装起来了 我们只需要了解文件相关的一些…

【前端 | CSS】滚动到底部加载,滚动监听、懒加载

背景 在日常开发过程中&#xff0c;我们会遇到图片懒加载的功能&#xff0c;基本原理是&#xff0c;滚动条滚动到底部后再次获取数据进行渲染。 那怎么判断滚动条是否滚动到底部呢&#xff1f;滚动条滚动到底部触发时间的时机和方法又该怎样定义&#xff1f; 针对以上问题我…

数据集成革新:去中心化微服务集群的无限潜能

在当今数据密集型的业务环境下&#xff0c;传统的集中式架构已经难以满足高可用性和高并发性的要求。而去中心化微服务集群则通过分散式的架构&#xff0c;将系统划分为多个小型的、独立部署的微服务单元&#xff0c;每个微服务负责特定的业务功能&#xff0c;实现了系统的高度…

docker搭建opengrok环境

引言&#xff1a; 由于这几天开始 http://aospxref.com/ 网站没法用了。用习惯了opengrok的方式看AOSP的源码&#xff0c;其他的在线查看源码的网站用起来都不是很理想。所以考虑搭建一个环境。 首先网上看了下opengrok的环境搭建的方式&#xff0c;最终还是采用docker的方…

基于C#的无边框窗体阴影绘制方案 - 开源研究系列文章

今天介绍无边框窗体阴影绘制的内容。 上次有介绍使用双窗体的方法来显示阴影&#xff0c;这次介绍使用API函数来进行绘制。这里使用的是Windows API函数&#xff0c;操作系统的窗体也是用的这个来进行的绘制。 1、 项目目录&#xff1b; 下面是项目目录&#xff1b; 2、 函数介…

日常BUG——SpringBoot模糊映射

&#x1f61c;作 者&#xff1a;是江迪呀✒️本文关键词&#xff1a;日常BUG、BUG、问题分析☀️每日 一言 &#xff1a;存在错误说明你在进步&#xff01; 一、问题描述 SpringBoot在启动时报出如下错误&#xff1a; Caused by: java.lang.IllegalStateExceptio…

ARM处理器

1、RISC处理器&#xff1a; RISC (Reduced Instruction Set Computer) 微处理器是一种计算机微处理器架构&#xff0c;其设计原则是通过简化指令集来提高执行速度。 (1)、RISC处理器的设计理念&#xff1a; 简化指令集&#xff1a;RISC 微处理器的指令集非常精简&#xff0c…

文件批量重命名001到100

文件批量重命名001到100如何搞定&#xff1f;这是一个许多朋友都在热议的话题&#xff0c;今天我将向大家介绍这方面的内容&#xff0c;希望你会喜欢。总的来说&#xff0c;文件重命名快捷键CtrlF2在日常工作中非常实用。它可以轻松快速地完成文件和文件夹的重命名操作&#xf…