昨晚升级macos发现flutter项目运行不了报错如下Warning:CocoaPodsnotinstalled.Skippingpodinstall.CocoaPodsisusedtoretrievethei0Sandmac0Splatformside'splugincodethatrespondsWithoutCocoapods,pluginswillnotworkoniosormacOsvourpluginFormoreinfo,seehttps://flutter.dev/platform-pluginsToinstallseehttps://guides,cocoapods.org
重新安装Cocoapods（2023.4.19）做ios或flutter开发时，经常会遇到添加依赖过后podinstall卡住，或者其他的一些奇奇怪怪的问题，如果花了很长时间都没有解决的话可以试试重新安装Cocoapods，这在大多数情况下都能有所帮助一、卸载cocoapods1.打开终端2.whichpod whichpod rm-rf/user/local/opt/ruby/bin/pod（此处可能不同）3.gemlist下面是卸载包的命令，如果安装了多个版本的cocoapods，卸载时加版本号sudogemuninstallcocoapodssudogemuninstallcocoapo
写在前面本文一起看下如何挂载本地的磁盘到POD中。1：都需要哪些API对象现实世界中的存储设备有非常非常多的种类，如本文要分析的计算机磁盘，还包括NFS(一种网络磁盘存储协议)，Ceph（一种分布式的文件存储系统），不管是哪种方式，最终都是通过将数据存储到硬盘来实现持久化，但是不同种类写入数据的方式是不相同的，k8s针对这些不同的存储目标进行抽象定义了PersistentValumeAPI对象，如下：dongyunqi@mongodaddy:~/k8s$kubectlapi-resources|egrep-w'PersistentVolume|KIND'NAMESHORTNAMESAPIVER
写在前面本文一起看下如何挂载本地的磁盘到POD中。1：都需要哪些API对象现实世界中的存储设备有非常非常多的种类，如本文要分析的计算机磁盘，还包括NFS(一种网络磁盘存储协议)，Ceph（一种分布式的文件存储系统），不管是哪种方式，最终都是通过将数据存储到硬盘来实现持久化，但是不同种类写入数据的方式是不相同的，k8s针对这些不同的存储目标进行抽象定义了PersistentValumeAPI对象，如下：dongyunqi@mongodaddy:~/k8s$kubectlapi-resources|egrep-w'PersistentVolume|KIND'NAMESHORTNAMESAPIVER
这三个概念是云计算中很常见的概念，但三者之间的关系一直没太搞明白，最近搜罗一番并整理一下，记录于此，以备后查。在聊这个三角关系前，需要说一下当前主流云的类型：第一类是以先驱AWS为首的公有云，公有云是云服务商自建或租用机房，通过Internet向用户提供服务，用户只能租用公有云服务，公有云由云服务商来建设和运营；第二类是私有云，微软、VMware等搞的比较high，用户需要负责私有云的场地、运营甚至硬件设备，并花钱向私有云提供商购买云软件和维保，一般私有云的云服务只对内部提供服务；第三种是混合云，一般是指包含有公有云和私有云的资源的云环境。说明Region、AZ和POD前，需要明确是基于公有云
K8S集群中Pod资源处于CrashLoopBackOff状态排查思路文章目录K8S集群中Pod资源处于CrashLoopBackOff状态排查思路1.Pod资源处于CrashLoopBackOff状态的原因2.Pod资源处于CrashLoopBackOff状态的排查思路3.资源限制问题导致Pod处于CrashLoopBackOff状态1.Pod资源处于CrashLoopBackOff状态的原因CrashLoopBackOff状态一般都是Pod资源中的容器出现了问题，可以有以下几点原因：容器中部署的程序存在Bug，无法正常启动，就会出现此状态，可以查询容器的启动日志，从日志中获取重要线索，逐个
K8S集群中Pod资源处于CrashLoopBackOff状态排查思路文章目录K8S集群中Pod资源处于CrashLoopBackOff状态排查思路1.Pod资源处于CrashLoopBackOff状态的原因2.Pod资源处于CrashLoopBackOff状态的排查思路3.资源限制问题导致Pod处于CrashLoopBackOff状态1.Pod资源处于CrashLoopBackOff状态的原因CrashLoopBackOff状态一般都是Pod资源中的容器出现了问题，可以有以下几点原因：容器中部署的程序存在Bug，无法正常启动，就会出现此状态，可以查询容器的启动日志，从日志中获取重要线索，逐个
需求描述提示：做到举一反三就要学会使用help信息找出标签是name=cpu-user的Pod，并过滤出使用CPU最高的Pod，然后把它的名字写在已经存在的/opt/cordon.txt文件里分析：了解pod指标，主要需要关注，CPU与内存占用率；生产环境，可能有几十个pod，我们为了使其便于快速检索到需要的pod，可以学会添加参数，使其按照特定的标准排序，参数很多，我们没必要全部记住，学会help一劳永与。解决方案：1、执行命令：kubectltoppo--sort-by=memory-h显示信息如图：由此可知这里可以，选择的选项有cpu和内存的数值由大到小排序。2、根据帮助信息可知，获取我
K8s创建Pod时，使用kubectldescribe命令查看Pod事件，发现在拉取镜像前出现报错，报错内容为：Failedtocreatepodsandbox:open/run/systemd/resolve/resolv.conf:nosuchfileordirectory该文件为DNS配置文件，一般由systemd-resolved服务管理，不能由用户修改。那些指点的人说把Master里的复制一份到Node中的人，实际上是行不通的。如果你的systemd-resolved服务状态是active的，那么本文的方法不适用于你的情况，如果服务状态是关闭的，那么启动该服务，再次进行Pod的创建即
查看pod或者deployment信息deployment：kubectlgetdeployment-n命名空间pod：kubectlgetpod-n命名空间删除pod或者deployment删除pod：kubectldeletepodpod名>-n命名空间>可是，此时你会发现刚刚删除的pod开始重构。那是因为pod的上级deployment仍然存在，k8s会启动容灾机智，再拉一个新pod。想要彻底删除pod，直接干掉它上层的deployment就可以删除deployment：kubectldeletedeploymentdeployment名>-n命名空间>干掉deployment，里面的p
