一、环境准备（所有节点）
1、节点信息
k8s-master：192.168.101.1
k8s-node1：192.168.101.2
k8s-node2：192.168.101.3

2、系统信息
CentOS Linux release 7.8.2003 (Core)

3、关闭selinux
sed -i 's/enforcing/disabled/' /etc/selinux/config
setenforce 0

4、关闭防火墙
systemctl stop firewalld
systemctl disable firewalld

5、关闭swap（测试环境可不关闭）
vi /etc/fstab
去除swap配置，并reboot
PS：为了应用发生OOM时，使其被系统kill掉，及时发现问题

6、设置主机名和hosts
主节点：k8s-master
工作节点1：k8s-node1
工作节点2：k8s-node2
vi /etc/hosts
1）k8s-master节点
127.0.0.1 k8s-master
192.168.101.2 k8s-node1
192.168.101.3 k8s-node2
2）k8s-node1节点
127.0.0.1 k8s-node1
192.168.101.1 k8s-master
192.168.101.3 k8s-node2
3）k8s-node2节点
127.0.0.1 k8s-node2
192.168.101.1 k8s-master
192.168.101.2 k8s-node1

verdaccio是管理npm包的私服，类似于maven私服吧。自己开发的包可以放上去，也可以作为公共包的缓存，本地没有再到中央库去拉

1、安装node.js
略过

2、安装verdaccio
npm install -g verdaccio

3、启动服务
1）启动
verdaccio -l 0.0.0.0:4873
*** WARNING: Verdaccio doesn't need superuser privileges. Don't run it under root! ***
warn --- config file - /root/.config/verdaccio/config.yaml
warn --- Verdaccio started
warn --- Plugin successfully loaded: verdaccio-htpasswd
warn --- Plugin successfully loaded: verdaccio-audit
warn --- http address - http://0.0.0.0:4873/ - verdaccio/4.7.2
外网可以通过http://IP:4873来访问了，但是现在只是运行在控制台上，日志也是往控制台打的
2）添加配置
vi /root/.config/verdaccio/config.yaml
在最后加入：
listen: 0.0.0.0:4873

CentOS7的systemd使用journal来记录管理日志，journal记录的日志为二进制格式，可以通过管理工具维护。对应的服务为systemd-journald
你会发现在/var/log/下少了很多日志文件，而/var/log/journal占用了大量的磁盘空间

1、查看服务
[root@docker log]# systemctl status systemd-journald.service
● systemd-journald.service - Journal Service
Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static; vendor preset: disabled)
Active: active (running) since 五 2020-06-26 03:38:23 UTC; 1 day 11h ago
Docs: man:systemd-journald.service(8)
man:journald.conf(5)
Main PID: 79 (systemd-journal)
Status: "Processing requests…"
Tasks: 1
Memory: 7.0M
CGroup: /system.slice/systemd-journald.service
└─79 /usr/lib/systemd/systemd-journald
6月 19 13:54:37 docker systemd-journal[77]: Journal stopped
6月 19 13:54:52 docker systemd-journal[77]: Runtime journal is using 8.0M (max allowed 307.2M, trying to leave 460.8M free of 2.9G available → current limit 307.2M).
6月 19 13:54:52 docker systemd-journal[77]: Journal started
6月 19 13:54:53 docker systemd-journal[77]: Permanent journal is using 328.0M (max allowed 4.0G, trying to leave 4.0G free of 74.2G available → current limit 4.0G).
6月 19 13:54:53 docker systemd-journal[77]: Time spent on flushing to /var is 56.281ms for 31 entries.
6月 26 03:38:12 docker systemd-journal[77]: Journal stopped
6月 26 03:38:23 docker systemd-journal[79]: Runtime journal is using 8.0M (max allowed 307.2M, trying to leave 460.8M free of 2.9G available → current limit 307.2M).
6月 26 03:38:23 docker systemd-journal[79]: Journal started
6月 26 03:38:24 docker systemd-journal[79]: Permanent journal is using 328.0M (max allowed 4.0G, trying to leave 4.0G free of 47.7G available → current limit 4.0G).
6月 26 03:38:24 docker systemd-journal[79]: Time spent on flushing to /var is 51.714ms for 22 entries.

2、查看使用磁盘空间
[root@docker log]# journalctl --disk-usage
Archived and active journals take up 336.0M on disk.

3、清理命令
格式：
journalctl --vacuum-size=BYTES：保留多大的日志
journalctl --vacuum-time=TIME：移除多久以前的日志
例子：
保留一周的日志
journalctl --vacuum-time=1w
保留500MB的日志
journalctl --vacuum-size=500M

4、查看当前日志
journalctl -f

5、查看指定应用日志
journalctl -xeu httpd

参考资料：
https://www.cnblogs.com/leigepython/p/10302056.html

1、-d：指定解压目录
2、-O：指定字符集
3、例子：unzip -O GB18030 -d ./cos1 cos.zip

发现一个奇怪的现象，gitlab有时打开报502，多刷几次可以正常打开。所以并不是端口被占用
网上提供了一个分析的方法：
1、gitlab-ctl status
查看进程是否正常启动
2、/var/log/gitlab
下的日志有没有报错
3、gitlab-ctl tail [process name]
查看对应进程的情况

参考资料：
https://www.liangzl.com/get-article-detail-27713.html
https://segmentfault.com/a/1190000017436142

yum update时报错：
错误：rpmdb: BDB0113 Thread/process 9751/139849321973824 failed: BDB1507 Thread died in Berkeley DB library
错误：db5 错误(-30973) 来自 dbenv->failchk：BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
错误：无法使用 db5 - (-30973) 打开 Packages 索引
错误：无法从 /var/lib/rpm 打开软件包数据库
CRITICAL:yum.main:
Error: rpmdb open failed

解决办法：
cd /var/lib/rpm
rm -rf __db*
rpm --rebuilddb
yum repolist

再执行：
yum update

1、由于网络不好，导致yum命令中断，再次执行时提示
Another app is currently holding the yum lock; waiting for it to exit…

2、解决办法
rm -f /var/run/yum.pid
yum install yum-utils
yum clean all
yum-complete-transaction --cleanup-only
yum history redo last

3、安装yum-utils包时提示
There are unfinished transactions remaining. You might consider running yum-complete-transaction, or "yum-complete-transaction --cleanup-only" and "yum history redo last", first to finish them. If those don't work you'll have to try removing/installing packages by hand (maybe package-cleanup can help).
The program yum-complete-transaction is found in the yum-utils package.
以后yum-utils包要事先安装好

4、RPM数据库错误问题
事务处理完后，执行yum update还是报错：
--> 解决依赖关系完成
错误：软件包：7:device-mapper-libs-1.02.164-7.el7_8.1.x86_64 (@updates)
需要：device-mapper = 7:1.02.164-7.el7_8.1
正在删除: 7:device-mapper-1.02.164-7.el7_8.1.x86_64 (@updates)
device-mapper = 7:1.02.164-7.el7_8.1
更新，由: 7:device-mapper-1.02.164-7.el7_8.2.x86_64 (updates)
device-mapper = 7:1.02.164-7.el7_8.2
可用: 7:device-mapper-1.02.164-7.el7.x86_64 (base)
device-mapper = 7:1.02.164-7.el7
您可以尝试添加 --skip-broken 选项来解决该问题
** 发现 6 个已存在的 RPM 数据库问题， 'yum check' 输出如下：
7:device-mapper-libs-1.02.164-7.el7_8.2.x86_64 是 7:device-mapper-libs-1.02.164-7.el7_8.1.x86_64 的副本
7:device-mapper-libs-1.02.164-7.el7_8.2.x86_64 有缺少的需求 device-mapper = ('7', '1.02.164', '7.el7_8.2')
mesa-khr-devel-18.3.4-7.el7_8.1.x86_64 是 mesa-khr-devel-18.3.4-7.el7.x86_64 的副本
mesa-libglapi-18.3.4-7.el7_8.1.x86_64 是 mesa-libglapi-18.3.4-7.el7.x86_64 的副本
systemd-219-73.el7_8.6.x86_64 是 systemd-219-73.el7_8.5.x86_64 的副本
systemd-libs-219-73.el7_8.6.x86_64 是 systemd-libs-219-73.el7_8.5.x86_64 的副本
Warning: Some duplicates were not removed because they are required by installed packages.
You can try --cleandupes with --removenewestdupes, or review them with --dupes and remove manually.

现象是本机rpm数据库里记录了某个rpm包多个版本（可能事实上只装了一个版本）

查看软件包信息，发现存在多条信息：
rpm -qa | grep systemd
systemd-libs-219-73.el7_8.6.x86_64
systemd-219-73.el7_8.6.x86_64
systemd-libs-219-73.el7_8.5.x86_64
systemd-219-73.el7_8.5.x86_64
systemd-sysv-219-73.el7_8.5.x86_64

多了两条重复的：
systemd-libs-219-73.el7_8.5.x86_64
systemd-219-73.el7_8.5.x86_64

先解决xxx是xxx的副本：
rpm -e --noscripts device-mapper-libs-1.02.164-7.el7_8.2.x86_64
rpm -e --noscripts mesa-khr-devel-18.3.4-7.el7_8.1.x86_64
rpm -e --noscripts mesa-libglapi-18.3.4-7.el7_8.1.x86_64
rpm -e --noscripts systemd-219-73.el7_8.6.x86_64
rpm -e --noscripts systemd-libs-219-73.el7_8.6.x86_64

清理冲突：
package-cleanup --cleandupes

重新执行yum update，解决

现象是docker stop执行成功，但是docker ps中容器还是up状态

1、试试kill命令
docker kill nginx

2、重启docker服务
systemctl restart docker

3、再启动服务
docker start nginx

原因为nginx对目录没有写文件权限，代码是存在宿主机的，文件夹权限为root用户

1、登陆nginx容器环境
docker exec -it nginx /bin/bash

2、查看目录/var/www/html都是root用户权限
ls -al /var/www/html

3、查看容器用户
cat /etc/passwd
发现：
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
而nginx一般是用www-data用户来运行，它的家目录就是/var/www

4、将/var/www下改为www-data用户
cd /var/www
chown -R www-data:www-data ./

5、再次尝试，可以更新了

6、查看宿主机目录权限有没有变
ls -al /appserver/code/
drwxr-xr-x 8 33 33 4096 4月 12 08:19 wordpress
也变成了uid为33，因为是目录映射到容器中。容器中的改动也反映在宿主机上

1、安装软件包
yum groupinstall "fonts"

2、修改/etc/locale.conf
LANG=zh_CN.utf8

3、重启
reboot