种草先生

记录遇到的问题,后面会一点点补充 Kubernetes使用到的端口 服务名 备注 需要的端口 kube-scheduler 调度服务 10251 tcp etcd 2379端口API 服务，2380端口peer 通信 2379，2380 tcp kube-controller-manager 容器管理 10252 tcp kube-apiserver apiserver 443 tcp 此端口随配置而变化 calico-typha 管理calico 5437 tcp kubelet 认证API 10250 tcp bird bgp通信 179 tcp kube-proxy 10249：对外提供 /metrics; 10256：对外提供 /healthz 的访问。 10249，10256 tcp calico-node 网络接口管理和监听、路由、ARP 管理、ACL 管理和同步、状态上报 9099 tcp vxlan vxlan协议端口 4789 udp 一, kubelet 1 查看节点状态 NotReady ...

1 部署驱动 参考官网的,需要自己改镜像 12345678helm install smb-csi . -n kube-systemkubectl get pod -n kube-systemNAME READY STATUS RESTARTS AGEcsi-attacher-smb-0 1/1 Running 0 16hcsi-provisioner-smb-0 2/2 Running 0 16hcsi-smb-2dfnn 2/2 Running 0 16hcsi-smb-nn5pp 2/2 Running 0 16hcsi-smb-q9pln 2/2 Running 0 16h 2 Storageclass 创建 Secret 1kubectl create secret -n...

简介 鉴于 inotify 存在一定问题，不满足 gitlab 数据同步需求，后续调研了 sersync ，sersync 克服了 inotify 的几个缺点。 inotify 最大的不足是会产生重复事件，或者同一个目录下多个文件的操作会产生多个事件(例如，当监控目录中有 5 个文件时，删除目录时会产生 6 个监控事件)，从而导致重复调用 rsync 命令。 vim 文件时，inotify 会监控到临时文件的事件，但这些事件相对于 rsync 来说是不应该被监控的。 inotify 只能记录下被监听的目录发生了变化（增，删，改）并没有把具体是哪个文件或者哪个目录发生了变化记录下来； rsync 在同步的时候，并不知道具体是哪个文件或目录发生了变化，每次都是对整个目录进行同步，当数据量很大时，整个目录同步非常耗时（rsync 要对整个目录遍历查找对比文件），因此效率很低；rsync 在同步时，只同步发生变化的文件或目录（每次发生变化的数据相对整个同步目录数据来说很小，rsync 在遍历查找对比文件时，速度很快），因此效率很高。 server 端 1...

Helm 常用命令 命令 描述 create 创建一个 chart 并指定名字 dependency 管理 chart 依赖 get 下载一个 release。可用子命令：all、hooks、manifest、notes、values history 获取 release 历史 install 安装一个 chart list 列出 release package 将 chart 目录打包到 chart 存档文件中 pull 从远程仓库中下载 chart 并解压到本地 helm pull stable/mysql --untar repo 添加，列出，移除，更新和索引 chart 仓库。可用子命令：add、index、list、remove、update rollback 从之前版本回滚 search 根据关键字搜索 chart。可用子命令：hub、repo show 查看 chart...

1 原理 Info 同一集群内的客户机只需要与该集群的 RR 直接交换路由信息，因此客户机只需要与 RR 之间建立 IBGP 连接，不需要与其他客户机建立 IBGP 连接，从而减少了 IBGP 连接数量。并采用独有的 Cluster_List 属性和 Originator_ID 属性防止路由环路。RR 向 IBGP 邻居发布路由规则如下： 从非客户机学到的路由，发布给所有客户机。 从客户机学到的路由，发布给所有非客户机和客户机（发起此路由的客户机除外）。 从 EBGP 对等体学到的路由，发布给所有的非客户机和客户机。 2 配置 Calico 2.1 关闭 node-to-node BGP 网络 Info 为保证 IBGP 对等体之间的连通性，需要在 IBGP 对等体之间建立全连接关系。假设在一个 AS 内部有 n 台设备，那么建立的 IBGP 连接数就为 n(n-1)/2。当设备数目很多时，设备配置将十分复杂，而且配置后网络资源和 CPU 资源的消耗都很大。Calico 默认是 Full-mesh 全互联模式，需要关闭 1234567891011cat...

单节点 1 备份 1.1 备份前 gitlab 的项目如图所示 1.2 检查后台迁移任务 在升级到新的主要版本之前，请确保所有后台迁移已完全完成 这一点很重要。在后台迁移完成之前进行升级可能会导致数据损坏。 可在 http://{gitlaburl}/admin/background_jobs 中查看 1.3 停掉服务 gitlab-ctl stop puma gitlab-ctl stop sidekiq 1.4 进行备份 1.4.1 全量备份 如果加 STRATEGY=copy 参数可以不需要停止服务,但是添加这个参数是增加一倍存储空间 gitlab-backup create 1.4.2 只备份数据库 gitlab data 要通过IaaS平台备份磁盘 gitlab-backup create SKIP=uploads,builds,artifacts,lfs,registry,pages,repositories 1.5 查看 12345# pwd/data/gitlab-data/data/backups# ll -htotal...

1 迁移规划 提前把数据库迁移到外部,参考: GitLab 迁移到外部数据库 | 云原生基站 准备 gitlab 集群,参考: GitLab Cluster | 云原生基站(里面别按照这文档写数据,都是测试用的) 同步原有 gitlab 数据到 nfs (因为数据量比较大,这部操作可能要一天作用) 修改原有 gialab 服务配置,使其变成 gitaly 测试没问题,切换 dns 解析到 rails 角色的负载均衡 2 同步数据 原有 gitlab 节点执行 2.1 安装工具 yum install rsync nfs-utils -y 2.2 挂载 NFS mount -t nfs 10.1.1.1:/gitlab-data /gitlab-dat 2.3 查看目录结构 12345678910111213141516171819├── config│ ├── docker-compose.yaml│ ├── gitlab.rb│ ├── ssl│ │ ├── gitlab-tst.ccops.cc.crt│ │ └──...

背景,当前单节点 gitlab 已经无法满足公司需求,gitlab 官网方案用的资源比较多,最好采用 3rails,gitaly,其中 gitaly 分片存储 可能发生的问题,其中某个 gitaly 节点宕机会导致当前节点的 project 无法访问 一, 准备工作 1 资源申请 名称 数量 端口 备注 rails 3 80(HTTP),443(TCP/HTTPS),2222(TCP) 对外 gitlab 服务 gitaly 3 9999(TCP),9236(TCP) gitlab 存储 负载均衡(F5) 1 80(HTTP),443(TCP/HTTPS),2222(TCP) rails 负载 存储(NFS) 1 (111,635,2049,4046)TCP/UDP plpgsql 1 5432(TCP) 版本>=12 redis 1 6379(TCP) 版本>=5 1.1 系统调优 参考: Linux系统调优 2 证书准备 2.1 gitaly 2.1.1 配置文件 2.1.1.1...

1 前期准备 准备生产 redis 和 pg 集群,在 pg 上创建一个新的无任何数据的库： gitlab 提前将新的 gitlab.rb 文件修改完成（添加外部 pg 和 redis 连接配置） 2 备份 2.1 检查后台迁移任务 在升级到新的主要版本之前，请确保所有后台迁移已完全完成 这一点很重要。在后台迁移完成之前进行升级可能会导致数据损坏。 可在 http://{gitlaburl}/admin/background_jobs 中查看 2.2 停掉服务 gitlab-ctl stop puma gitlab-ctl stop sidekiq 2.3 进行备份 gitlab-backup create SKIP=uploads,builds,artifacts,lfs,registry,pages,repositories 2.4 查看 12345# pwd/data/gitlab-data/data/backups# ll -htotal 3.4G-rwxr-xr-x 1 chrony polkitd 2.5G Jun 13 11:47...

网上搜的命令要么不全,要么写的太多,看这字多,自己总结了下 1 kubectl 自动补全 12345yum install bash-completionecho "source /usr/share/bash-completion/bash_completion" >> ~/.bashrcecho 'source <(kubectl completion bash)' >>~/.bashrcsource ~/.bashrctype _init_completion #检查是否安装成功 2 资源对象 2.1 工作负载型资源对象 POD，ReplicaSet，Deployment，StatefulSet，DaemonSet，Job，Cronjob … 2.2 服务发现及均衡资源对象 Service，Ingress, IngressRoute … 2.3...