Linux - Rsync


Linux - Rsync

一、 Linux -Rsync

Rsync 介绍

Rsync 是一款开源的备份工具，可以在不同主机之间进行同步，可实现全量备份与增量备份，因此非常适合用于架构中式备份或异地备份等应用。

备份方式：

假设客户端上有 file1 file2 file3 文件，服务端上有 file1 文件，现要将客户端的数据备份至服务器。

  • 全量备份：

    会将 客户端所有的数据file1 file2 file3 全部备份至服务端（效率慢，重复备份浪费时间，占用空间）

  • 增量备份：

    将客户端的 file2 file3 增量备份至服务端（不会重复备份文件，提高了备份效率，节省空间时间，适合异地备份）

Rsync 应用场景

Rsync 的数据同步有以下两种模式：

  • push：

    • 所有主机推送本地数据至 Rsync 备份服务器，会导致数据同步缓慢（适合少量数据备份）
    • webserver （推送） —> Rsync备份服务器（接收）

    Rsync-push

  • pull：

    • 在Rsync 备份服务端主动拉取所有主机上的数据，会导致备份服务器开销大
    • webserver —> Rsync 备份服务器（主动拉取，接受）
      Rsync-push

  • 大量服务器备份场景

    • 多 Server 备份

    Rsync-servers

  • 异地备份场景

    • 本地 Push 至本地备份服务器 —> 本地备份服务器 同步至 云端备份

    Rsync-cloud-server

Rsync 传输模式

Rsync 使用三种主要的数据传输方式

  • 本地方式

  • 远程方式

  • 守护进程

本地传输方式：

单个主机本地之间的数据传输（ 类似 Linux 中的 cp 命令 ）

1
2
3
4
5
6
7
8
9
# 本地拷贝数据命令
Usage: rsync [OPTION]... SRC [SRC]... [DEST]

# 本地拷贝数据示例
root@datarc:/# rsync -avz /etc/passwd /backup/
rsync			# 备份命令 （cp）
[OPTION]		# 选项
SRC				# 本地源文件
[DEST]			# 本地目标文件

远程通道传输方式：

通过 SSH 通道传输数据，类似 scp 命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# pull 拉取数据命令
Pull: rsync [OPTION]... [USER@]HOST:SRC [DEST]

# pull 拉取数据示例
root@datarc:/# rsync -avz root@10.1.1.1:/etc/passwd ./         # 拉取远程文件至当前路径
root@datarc:/# rsync -avz root@10.1.1.1:/root/ /backup/		   # 拉取远程目录下的所有文件 
root@datarc:/# rsync -avz root@10.1.1.1:/etc/passwd /backup/   # 拉取远程目录以及以下所有文件

pull			# 拉取，下载
rsync			# 备份命令 （cp）
[OPTION]		# 选项
[USER@]			# 目标主机的系统用户
HOST			# 目标主机 IP 地址或域名
SRC				# 目标主机源文件
[DEST]			# 下载至本地路径
1
2
3
4
5
6
7
8
9
10
11
12
13
# push 推送数据命令
Push: rsync [OPTION]... SRC [SRC]... [USER@]HOST:DEST

# push 推送数据示例
root@datarc:/# rsync -avz /backup/data/0807 root@10.1.1.1:/backup   # 拉取远程文件至当前路径

push			# 推送，上传
rsync			# 备份命令 （cp）
[OPTION]		# 选项
SRC...          # 本地源文件
[USER@]			# 目标主机的系统用户
HOST			# 目标主机 IP 地址或域名
[DEST]			# 推送目标位置

Rsync 借助 SSH 协议同步数据存在的缺陷

  • 使用系统用户（有安全隐患）
  • 使用普通用户（导致权限不足情况）
  • 守护进程传输方式：rsync 自身非常重要的功能（不使用系统用户，更加安全）
1
2
3
4
5
6
7
8
9
10
11
12
# pull 拉取数据命令
pull: rsync [OPTION]... rsync://[USER@]HOST[:PORT]/SRC [DEST]

# pull 拉取 rsync 备份服务器 "backup 模块" 至 本地 "/mnt 目录"
root@datarc:/# rsync -avz rsync_backup@10.1.1.1::backup/ /mnt/ --password-file=/etc/rsync.passwd

rsync			# 备份命令 （cp）
[OPTION]		# 选项
[USER@]			# 远程主机用户（虚拟用户）
HOST::			# 远程主机地址
SRC...		    # rsync 中配置的远程主机模块（不是 Linux 目录）
[DEST]			# 下载至本地路径
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# push 推送数据命令
Push: rsync [OPTION]... SRC [SRC]... rsync://[USER@]HOST[:PORT]/DEST

# push 将 本地 "/mnt 目录" 推送至 rsync 备份服务器 "backup 模块"
root@datarc:/# rsync -avz /mnt/ rsync_backup@10.1.1.1::backup/ --password-file=/etc/rsync.passwd

rsync  				# 备份命令 （cp）
[OPTION]  			# 选项
SRC...  			# 本地源文件
[USER@]  			# 远程主机用户（虚拟用户）
HOST::  			# 远程主机地址
[DEST]  			# rsync 中配置的远程主机模块（不是 Linux 目录）

-a  				# 归档模式；等于-rlptgoD
-v  				# 详细模式输出，打印速率，文件数量等信息
-z  				# 传输时进行压缩以提高效率
-r  				# 传递传输目录以及子目录，即目录下的所有目录都同样传输
-t  				# 保持文件时间信息
-o  				# 保持文件属主信息
-p  				# 保持文件权限
-g  				# 保持文件属组信息
-l  				# 保持 软连接
-P  				# 显示同步的过程以及传输时的进度等信息
-D  				# 保持设备文件信息
-L  				# 保留软链接指向的目标文件
-e  				# 使用的信道协议，指定代替 rsh 的 shell 程序
--exclude=PATTERN  	# 指定排除不需要传输的文件模式
--exclude-from=file # 文件名所在的目录文件
--bwlimit=100    	# 限速传输
--partial   		# 断点续传
--delete    		# 让目标目录和源目录数据保持一致

Rsync 服务实践

主机角色 外网 IP（NAT） 内网 IP （LAN） 主机名称
Rsync 服务端 10.0.0.1 192.168.1.1 datarc-backup
Rsync 客户端 10.0.0.2 192.168.1.2 datarc-nfs

Rsync 服务端

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
1. 安装 rsync
root@datarc-backup:# yum -y install rsync || apt install -y rsync

2. 配置 /etc/rsyncd.conf

root@datarc-backup:/home/datarc# cat /etc/rsyncd.conf 
uid = rsync     # 运行进程的用户
gid = rsync     # 运行进程的用户组
port = 873      # 监听的端口
fake super = yes # 无需让 rsync 以 root 身份运行，允许接受文件的完整属性
use chroot = no  # 禁锢推送的数据至某个目录，不允许跳出该目录
max connections = 200  # 最大连接数
timeout = 600  # 超时时间
ignore errors  # 忽略错误信息
read only = false  # 对备份数据可读写
list = false  # 不允许查看模块信息
auth users = rsync_backup # 定义虚拟用户，作为连接认证用户
secrets file = /etc/rsync.passwd  # 定义 rsync 服务用户连接认证密码文件路径
log file = /var/log/rsyncd.log

[backup] # 定义模块信息
comment = welcome to datarc backup !!! # 模块注解信息
path = /backup  #定义接受备份数据目录

3. 创建用户（运行 rsync 服务的用户身份）
	(1) 创建 rsync 用户，不允许登录不创建家目录
root@datarc-backup:# useradd -M -s /sbin/nologin rsync

	(2)创建备份目录（磁盘空间足够大），授权 rsync 用户作为属主
root@datarc-backup:# mkdir /backup && chown -R rsync.rsync /backup/

4. 创建虚拟用户密码文件，授权 600 安全权限（用于客户端连接时使用的用户）
root@datarc-backup:# echo "rsync_backup:datarc" >/etc/rsync.passwd && chmod 600 /etc/rsync.passwd

5. 启动 rsync 服务，并加入开机自启
root@datarc-backup:# systemctl start rsyncd && systemctl enable rsyncd

6. 检查 rsync 873 端口 是否处于监听状态
root@datarc-backup:# netstat -tnulp |grep 873

客户端

1
2
3
4
5
6
7
1. rsync 客户端 仅需配置虚拟用户的密码，并授权为 600 安全权限
	(1) 适合终端执行指定用户密码文件
root@datarc-nfs:# yum -y install rsync || apt install -y rsync
root@datarc-nfs:# echo "datarc" > /etc/rsync.pass && chmod 600 /etc/rsync.pass

	(2)脚本中使用
root@datarc-nfs:# export RSYNC_PASSWORD=datarc

实践

1
2
3
1. 客户端推送 backup 目录下的所有内容 至 Rsync 服务端
root@datarc-nfs:# export RSYNC_PASSWORD=datarc
root@datarc-nfs:# rsync -avz /backup/ rsync_backup@192.168.1.1::backup/
1
2
3
2. 客户端 拉取 rsync 服务端 backup 模块数据至本地客户端的 /backup 目录
root@datarc-nfs:# export RSYNC_PASSWORD=datarc
root@datarc-nfs:# rsync -avz rsync_backup@192.168.1.1::backup /backup/
1
2
3
4
5
6
7
8
3. rsync 实现数据无差异同步
# 推送数据至远端：远端与本地保持一致，本地没有 1.txt，远端1.txt会被删除，造成服务端数据丢失
root@datarc-nfs:# export RSYNC_PASSWORD=datarc
root@datarc-nfs:# rsync -avz --delete /backup/ rsync_backup@192.168.1.1::backup

# 拉取远端数据：本地与远端保持一致，例如：远端没有 1.txt 本地有 1.txt 则会被删除，造成客户端数据丢失
root@datarc-nfs:# export RSYNC_PASSWORD=datarc
root@datarc-nfs:# rsync -avz --delete rsync_backup@192.168.1.1::backup/ /backup/
1
2
3
4
4. rsync 的 Limit 限速
# 企业案例：使用 rsync 拉取备份数据时，由于文件过大导致内部交换机带宽被占满，导致用户的请求无法响应
root@datarc-nfs:# export RSYNC_PASSWORD=datarc
root@datarc-nfs:# rsync -avz --bwlimit=1 rsync_backup@192.168.1.1::backup/ /backup/

Rsync 备份案例

已知 3 台服务器主机名分别为 web01 backup nfs 主机信息见下表：

角色 外网IP （NAT） 内网IP （LAN） 主机名
WEB eth0:10.0.0.1 eth1:192.168.1.1 web01
NFS eth0:10.0.0.2 eth1:192.168.1.2 nfs01
Rsync eth0:10.0.0.3 eth1:192.168.1.3 backup

客户端需求

  • 客户端提前准备存放的备份的目录，目录规则如下：/backup/nfs_192.168.1.2_2020-0101
  • 客户端在本地打包备份（系统配置文件、应用配置等）拷贝至 /backup/nfs_192.168.1.2_2020-0101
  • 客户端最后将备份的数据进行推送至备份服务器
  • 客户端每天凌晨 1 点定时执行该脚本
  • 客户端服务器本地保留最近 7 天的数据，避免浪费磁盘空间

服务端需求

  • 服务端部署 rsync，用于接收客户端推送过来的备份数据
  • 服务端需要每天校验客户端推送过来的数据是否完整
  • 服务端需要将每天校验的结果通知给管理员
  • 服务端仅保留 6 个月的备份数据，其余的数据全部删除

注意： 所有服务器的备份目录必须为 /backup

1
2
3
4
5
6
7
8
9
10
11
12
13
# 建议备份的数据内容如下：

1. 开机自启动配置文件     设备挂载配置文件      本地内网配置文件   （系统配置文件）
	/etc/rc.local		/etc/fstab		   /etc/hosts	
	
2. cron 定时任务		firewalld 防火墙  	  脚本目录		（重要目录）
	/var/spool/cron/   	/etc/firewalld	   /server/scripts
	
3. 系统日志文件
	/var/log/		//系统安全日志、sudo 日志、内核日志、rsyslog 日志
	
4. 应用程序服务配置文件 
	nginx、PHP、mysql、redis、Docker...

客户端实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
1. 客户端备份实现思路，脚本每天凌晨 01 点定时执行一次
  （打包 --> 标记 --> 推送 --> 保留最近 7 天的文件）
  
root@nfs01:/# cat /server/scripts/client_rsync_backup.sh
#!/usr/bin/bash

# 1. 定义变量
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
Host=$(hostname)
Addr=$(ifconfig eth1|awk 'NR==2{print $2}')
Date=$(date +%F)
Dest=${Host}_${Addr}_${Date}
path=/backup

# 2. 创建备份目录
[ -d $Path/$Dest ] || mkdir =p $Path/$Dest

# 3. 备份对应的文件
cd / && \
[ -f $Path/$Dest/system.tar.gz ] || tar czf $Path/$Dest/system.tar.gz etc/fstab etc/rsyncd.conf && \
[ -f $Path/$Dest/log.tar.gz ] || tar czf $Path/$Dest/logo.tar.gz var/log/messages var/log/secure && \

# 4. 携带 md5 验证信息
[ -f $Path/$Dest/flag ] || md5sum $Path/$Dest/*.tar.gz >$Path/$Dest/flag_$Date

# 5. 推送本地数据至备份服务器
export RSYNC_PASSWORD=datarc
rsync -avz $Path/ rsync_backup@192.168.1.1::backup

# 6. 本地保留最近 7 天的数据
find $Path/ -type d -mtime +7|xargs rm -rf
  
  
 2. 客户端编写定时任务，让备份每天凌晨 1 点执行
root@nfs01:/# crontab -l
 00 01 * * * /bin/bash /server/scripts/backup_rsync.sh &>/dev/null

服务端实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
1. 服务端校验客户端推送的数据的完整性
  （校验 --> 存储校验结果 --> 将保存的结果通过邮件发送给管理员 --> 保留最近 180 天的数据）
root@backup:/# yum -y install mailx -y || apt install -y mailx 
root@backup:/# cat /etc/mail.rc
set from=邮箱
set smtp=smtps://smtp.qq.com:465
set smtp-auth-user=邮箱
set smtp-auth-passwd=#客户端授权码
set smtp-auth=login
set ssl-verify=ignore
set nss-config-dir=/etc/pki/nssdb/

2. 服务端校验、以及邮件通知脚本
root@backup:/# mkdir /server/scripts -p
root@backup:/# cat /server/scripts/check_backup.sh
#!/usr/bin/bash
#1. 定义全局的变量
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin

#2. 定义局部变量
path=/backup
Date=$(date +%F)

#3. 查看 flag 文件，并对该文件进行校验，然后将 校验结果保存至 result_time
find $Path/ -type f -name "flag_$Date"|xargs md5sum -c >$Path/result_${Date}

#4. 将校验的结果发送邮件给管理员
mail -s "Rsync Backup $Date" XXX@qq.com <$Path/result_${Date}

#5.删除超过 7 天的校验结果文件，删除超过 180 天的备份数据文件
find $Path/ -type f -name "resule*" -mtime +7|xargs rm -f
find $Path/ -type d -mtime +180|xargs rm -rf 

3. 服务端编写定时任务脚本
root@backup:/# crontab -l
00 05 * * * /bin/bash /server/scripts/check_backup.sh &>/dev/null

展开全文 >>

K8s集群：命名空间（Namespace）


K8s集群：Pod 与 Deployment

一、k8s - Pod 介绍

创建第一个 Pod 资源

Pod 可以理解为一组容器，是 K8s 最小的调度单位。首先我们创建第一个 Pod 资源来运行我们的项目。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# cat datarc-test-pod.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: datarc
  
---

apiVersion: v1
kind: Pod
metadata:
  namespace: datarc
  name: datarc-test-pod
  labels:
    app: nginx
spec:
  containers:
  - name: app1
    image: nginx:1.13
    ports:
      - containerPort: 80
      
# 创建
kubectl apply -f datarc-test-pod.yaml

二、Deployment 介绍

创建第一个 Deployment

因为 Pod 是最小的调度单位，我们通常会创建 Deployment 对象，通过 Deployment 对象来进行管理 Pod。

1
2
问：为什么一般不创建 Pod 对象呢？
答：因为创建的 pod 对象，如果挂掉是不会被 k8s 感知和重启的，创建 Deployment 对象可以管理多组 pod 对象，如果 pod 挂掉，Deployment 对象则会重新拷贝一个 pod 的副本出来，所以我们需要创建 Deployment 对象而不是创建 Pod 对象。

我们通过创建 YAML 的描述文件，k8s 根据这个 YAML来创建相对应的资源对象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# cat datarc-deployment-test1.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: datarc
  
---

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: datarc
  name: datarc-test-pod
  labels:
    app: datarc
spec:
  replicas: 2
  selector:
    matchLabels:
      app: datarc
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: datarc
    spec:
      containers:
      - image: nginx:1.13
        name: datarc-1
        resources: {}
status: {}

# 创建
kubectl apply -f datarc-deployment-test1.yaml

相关命令：

  • 查看 Deployment

    kubectl get deployments -n

  • 查看 Pod

    kubectl get pods -n

    kubectl describe pods -n datarc

  • 查看 logs 日志

    kubectl logs -n

  • 进入 exec

    kubectl exec – curl -s

三、Service 暴露服务

是运行 Pod Ip 是 Docker 网桥的 IP 地址段进行分配的，通常是一个虚拟的二层网络，外部网络并没有办法访问，并且，Pod Ip是随时会变的，不是固定的，k8s 引入了 Service 的概念，通过 Service 管理这些 Pod，Service 创建后的 Service IP 是固定的。但是 Service IP(Cluster IP) 是一个虚拟的 IP ,由 Kubernetes 管理和分配 IP 地址，外部网络无法访问。k8s 有三种方式暴露 Service 给外部网络访问。

1
2
3
4
5
6
7
8
9
问：为什么Pod的IP会变化？
答：Kubernetes 具有强大的副本控制能力，能保证在任意副本（Pod）挂掉时自动从其他机器启动一个新的，所以说，这个 Pod 可能在任何时刻出现在任何节点上，也可能在任何时刻死在任何节点上；那么自然随着 Pod 的创建和销毁，Pod IP 肯定会动态变化

问：如何解决 Pod 的 IP 会变的问题？
答：当 Pod 宕机后重新生成时，其 IP 等状态信息可能会变动，Service 会根据 Pod 的 Label 对这些状态信息进行监控和变更，保证上游服务不受 Pod 的变动而影响。

问：什么是 Service ？
答：Kubernetes Service 定义了：Service 是一种可以访问 Pod 逻辑分组的策略， Service 通常是通过 Label Selector访问 Pod 组; 
   Service 能够提供负载均衡的能力，但是在使用上有些限制：只提供 4 层负载均衡能力，而没有 7 层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上 4 层负载均衡是不支持的。

Service 有以下几种类型：

  • ClusterIp ：默认类型，自动分配一个仅 ClusterIP 内部可以访问的虚拟服务 IP，集群内部有效，适用于集群内多个 service 之间互相通讯；

imges

  • NodePort：在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过: NodePort 来访问该服务，外层配合 Nginx 对用户提供访问。

img

  • LoadBalane：在 NodePort 的基础上，借助 Cloud Provider 创建一个外部负载均衡器，并将请求转发到 NodePort

img

  • ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 Kubernetes 1.7或更高版本的kube-dns才支持。

Service 是怎么运行的：

  • 客户端访问节点时通过 iptables 实现
  • iptables 规则是通过 kube-proxy 写入
  • apiserver 通过监控 kube-proxy 去进行对服务和端点的监控
  • kube-proxy 通过 pod 的标签（ lables）去判断这个断点信息是否写入到 Endpoints 里

img

暴露服务的三种方式：

  • ClusterIP

    ClusterIP 主要在每个 node 节点使用 iptables ，将发向 ClusterIP 对应端口的数据，转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 service 下对应 pod 的地址和端口，进而把数据转发给对应的 pod 的地址和端口。

  • NodePort
    将服务的类型设置成 NodePort 每个集群节点都会在节点上打开一个端口， 对于 NodePort 服务， 每个集群节点在节点本身（因此得名叫 NodePort )上打开一个端口，并将在该端口上接收到的流量重定向到基础服务。该服务仅在内部集群 IP 和端口上才可访间， 但也可通过所有节点上的专用端口访问。

  • LoadBalane

    将服务的类型设置成 LoadBalance , NodePort 类型的一 种扩展，这使得服务可以通过一个专用的负载均衡器来访问， 这是由 Kubernetes 中正在运行的云基础设施提供的。 负载均衡器将流量重定向到跨所有节点的节点端口。客户端通过负载均衡器的 IP 连接到服务。

  • Ingress
    创建一个 Ingress 资源， 这是一 个完全不同的机制， 通过一 个IP地址公开多个服务,就是一个网关入口。

loadbalance 方式的 service 有 external IP，是对外的

ClusterIP

ClusterIP 主要在每个 node 节点使用 iptables ，将发向 ClusterIP 对应端口的数据，转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 service 下对应 pod 的地址和端口，进而把数据转发给对应的 pod 的地址和端口。

img

为了实现图上的功能，主要需要以下几个组件的协同工作：

apiserver：用户通过 kubectl 命令向 apiserver 发送创建 service 的命令， apiserver 接收到请求后将数据存储到 etcd 中 kube-proxy： Kubernetes的每个节点中都有一个叫做 kube-porxy 的进程，这个进程负责感知 service、 pod 的变化，并将变化的信息写入本地的 iptables 规则中iptables：使用 NAT 等技术将 virtualIP 的流量转至 endpoint 中创建 myapp-deploy.yaml 文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
#1. 创建 Service 的 YAML 描述文件
# cat datarc-deployment-test1-svc.yaml
apiVersion: apps/v1
kind: Namespace
metadata:
  name: datarc
  
---

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: datarc
  name: datarc-test-pod
  labels:
    app: datarc
spec:
  replicas: 2
  selector:
    matchLabels:
      app: datarc
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: datarc
    spec:
      containers:
      - image: nginx:1.13
        name: datarc-1
        resources: {}
status: {}

---

apiVersion: v1
kind: Service
metadata:
  namespace: datarc
  name: datarc-test-pod
spec:
  type: ClusterIP
  selector:
    app: datarc
  ports:
  - name: http
    port: 80
    targetport: 8080
 
 
# 创建 Service 资源
kubectl apply -f datarc-deployment-test1-svc.yaml

# 查看 SVC

> kubectl get svc
> kubectl describe svc -n <svcName>

NodePort

在 k8s 上可以给 Service 设置成 NodePort 类型，这样的话可以让 Kubernetes 在其所有节点上开放一个端口给外部访问（所有节点上都使用相同的端口号）， 并将传入的连接转发给作为 Service 服务对象的 pod。这样我们的 pod 就可以被外部请求访问。

  • （NodePort的原理在于在 Node上开了一个端口，将向该端口的流量导入到 kube-proxy，然后由 kube-proxy进一步到给对应的 pod）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
#1. 创建 Service 的 YAML 描述文件
# cat datarc-deployment-test1-svc.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: datarc
  
---

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: datarc
  name: datarc-test-pod
  labels:
    app: datarc
spec:
  replicas: 2
  selector:
    matchLabels:
      app: datarc
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: datarc
    spec:
      containers:
      - image: nginx:1.13
        name: datarc-1
        resources: {}
status: {}

---

apiVersion: v1
kind: Service
metadata:
  namespace: datarc
  name: datarc-svc
spec:
  type: NodePort
  selector:
    app: datarc
  ports:
  - name: http
    port: 80
    targetPort: 80
 
 
# 创建 Service 资源
kubectl apply -f datarc-deployment-test1-svc.yaml

注：spec.ports.nodePort这个参数是指Node节点对外开放访问的端口号，如果不指定，则Kubernetes会随机选择一个端口号

相关命令：

  • 查看 SVC

    kubectl get svc

    kubectl describe svc -n

NodePort总结

简单易用，但是服务一旦多起来，NodePort 在每个节点上开启的端口会及其庞大，而且难以维护，所以生产环境不建议这么使用

Ingress

采用 NodePort 方式暴露服务面临问题是，服务一旦多起来，NodePort 在每个节点上开启的端口会及其庞大，而且难以维护；如果采用 LoadBalane，每个服务都得开放一个公网IP，也会很庞大。这时候 Ingress 暴露服务就是一种很合适的方案。可以通过一个 Ingress 暴露多个服务。

在这里插入图片描述

在这里插入图片描述

我们可以能否使用一个Nginx直接对内进行转发呢？众所周知的是，Pod与Pod之间是可以互相通信的，而Pod是可以共享宿主机的网络名称空间的，也就是说当在共享网络名称空间时，Pod上所监听的就是Node上的端口。那么这又该如何实现呢？简单的实现就是在每个 Node 上监听 80，然后写好规则，因为 Nginx 外面绑定了宿主机 80 端口（就像 NodePort），本身又在集群内，那么向后直接转发到相应 Service IP 就行了，如下图所示：

在这里插入图片描述

Ingress 简单的理解就是你原来需要改 Nginx 配置，然后配置各种域名对应哪个 Service，现在把这个动作抽象出来，变成一个 Ingress 对象，你可以用 yaml 创建，每次不要去改 Nginx 了，直接改 yaml 然后创建/更新就行了；那么问题来了：”Nginx 怎么才能动态处理配置？”

注：Ingress资源时基于HTTP虚拟主机或URL的转发规则，需要强调的是，这是一条转发规则，没有任何功能，创建了Ingress对象，Ingress Controller会去动态感知和更新Ingress对象的转发规则

Ingress Controller 这东西就是解决 “Nginx 怎么才能动态处理配置” 的程序（可以简单理解成Ngixn程序，实际不一定，实现方案有很多种）；Ingress Controoler 通过与 Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，然后读取他，按照他自己模板生成一段 Nginx 配置，再写到 Nginx Pod 里，最后 reload 一下.

实际上，Ingress相当于一个7层的负载均衡器，是 kubernetes 对反向代理的一个抽象，它的工作原理类似于 Nginx，可以理解成在 Ingress 里建立诸多映射规则

Ingress Controller通过监听这些配置规则并转化成Nginx的反向代理配置 , 然后对外部提供服务。在这里有两个核心概念：

  • ingress：kubernetes中的一个对象，给管理员提供一个定义请求如何转发到 service 的规则的定义方法

  • ingress controller：具体实现反向代理及负载均衡的程序，对 ingress 定义的规则进行解析，根据配置的规则来实现请求转发，实现方式有很多，比如 Nginx, Contour, Haproxy

    在这里插入图片描述

Ingress（以Nginx为例）的工作原理如下：

  • 用户编写Ingress规则，说明哪个域名对应kubernetes集群中的哪个Service
  • Ingress控制器动态感知Ingress服务规则的变化，然后生成一段对应的Nginx反向代理配置
  • Ingress控制器会将生成的Nginx配置写入到一个运行着的Nginx服务中，并动态更新
  • 到此为止，其实真正在工作的就是一个Nginx了，内部配置了用户定义的请求转发规则

在这里插入图片描述

Ingress 安装

1
2
3
4
5
6
7
8
9
10
11
#1. 安装 Ingress 镜像
mkdir ingress-nginx && cd ingress-nginx && wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.3/deploy/static/provider/baremetal/deploy.yaml

#2. 执行下载好的 yaml
kubectl apply -f ingress-controller-1.1.yaml

#3. 默认在 ingress-nginx 这个命名空间下
kubectl get pods -n ingress-nginx

#4. 查看暴露的 service 端口
kubectl get pods,svc -n ingress-nginx

创建 Service

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
#1. ingress是代理 service 的，在使用 ingress 前要先有创建 service
kubectl get svc

#2. 以 nginx 的 service 为例
#cat datarc-ingress.yaml

apiVersion: apps/v1
kind: Namespace
metadata:
  name: datarc
  
---

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: datarc
  name: datarc-test-pod
  labels:
    app: datarc
spec:
  replicas: 2
  selector:
    matchLabels:
      app: datarc
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: datarc
    spec:
      containers:
      - image: nginx:1.13
        name: datarc-1
        resources: {}
status: {}

---

apiVersion: v1
kind: Service
metadata:
  namespace: datarc
  name: datarc-svc
spec:
  type: NodePort
  selector:
    app: datarc
  ports:
  - name: http
    port: 80
    targetPort: 80

---

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web1
spec:
  ingressClassName: "nginx"    # 可修改
  rules:
  - host: web.linuxnbg.com    # 可修改
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: datarc        # 可修改
            port: 			   # 可修改
              number: 80       # 可修改
              
#3. service 是此 ingress 绑定的 service
kubectl apply -f ingress1.yaml

Ingress 使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#1. 创建规则
 kubectl apply -f xxx.yaml 
 
#2. 查看
 kubectl get ingress
 
#3. 测试 
#本地电脑绑定hosts记录对应ingress里面配置的域名 例： web.linuxnbg.com
#例如这可以生成一个示例yaml
kubectl create ingress web1 --rule=host/path=web:80 --dry-run=client -o yaml

apiVersion: extensions/v1beta1		
kind: Ingress		
metadata:			
  name: ingress-myapp   
  namespace: default     
  annotations:          
    kubernetes.io/ingress.class: "nginx"
spec:     
  rules:   
  - host: web.linuxnbg.com   
    http:
      paths:       
      - path:       
        backend:    
          serviceName: datarc
          servicePort: 80

商务专线没有IP（联通），可换楼层，换楼的话，提前询问，是否能换 半年 网络
50M 2800 相对稳
100M 4750（5000） 相对稳
拨号上网
200M 2700 不稳
300M 3000 不稳
专线 有固定IP 50M 2万左右 稳

访问

1
2
3
4
5
6
7
8
#1. 查看 ingress 
kubectl get ingress

代表含义：images名、代理的service名、代理的域名、节点所在ip、服务走的端口

#2. 整个访问流程：
Service NodePort 访问 Ingress Controller：
域名（web.linuxnbg.com:32613） -> 公网负载均衡器(80) -> service nodeport（80:32613/TCP,443:31743/TCP）-> iptables/ipvs -> ingress controller Pod（nginx，基于域名分流） -> 分布在各个节点上的pod

ingress 切换宿主机 ip

1
2
3
4
5
6
7
8
9
10
11
12
#1. 在ingress的yaml中搜索containers
在 containers 上新加以下字段，与 containers同级
hostNetwork: True

#2. 重建
kubectl apply -f ingress-controller-1.1.yaml

#3. 访问
此时访问地址变成这样
hostNetwork访问Ingress Controller：
域名（web.linuxnbg.com:80） -> 公网负载均衡器(80) -> 宿主机80端口是ingress controller监听的 -> ingress controller（nginx，基于域名分流） -> 分布在各个节点上的pod
使用network的好处时他避开了service的代理，直接从宿主机访问，更方便快捷，坏处是只能访问他分配到的ip才能访问，没有service那么灵活

ingress总结
ingress 是一个全局入口（80和443），为集群中所有应用转发
公网负载均衡器在其中的作用：

  • 将k8s节点（内网）暴露到互联网上
  • 是互联网用户统一访问入口，特别是针对 service nodeport
  • 加强k8s网络安全

ingress 有两种部署方式，因为他本质上也是一个 pod

  • pod创建，用service在对他进行代理（ 官方默认 ）。
  • 直接共用宿主机网络，将端口暴露在宿主机。

在这里插入图片描述

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
#1. 安装 Ingress 镜像

mkdir ingress-nginx && cd ingress-nginx

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.3/deploy/static/provider/baremetal/deploy.yaml

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml &&
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml

ingress有两种部署方式，因为他本质上也是一个pod，所以他有两种暴露方式，第一种。pod创建，用service在对他进行代理。第二种。直接共用宿主机网络，将端口暴露在宿主机
官方yaml默认是由service代理的


# 修改mandatory.yaml文件中的仓库
# 修改quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0
# 为quay-mirror.qiniu.com/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0
# 创建ingress-nginx
[root@master ingress-controller]# kubectl apply -f ./

# 查看ingress-nginx
[root@master ingress-controller]# kubectl get pod -n ingress-nginx
NAME                                           READY   STATUS    RESTARTS   AGE
pod/nginx-ingress-controller-fbf967dd5-4qpbp   1/1     Running   0          12h

# 查看service
[root@master ingress-controller]# kubectl get svc -n ingress-nginx






#2. 拷贝配置文件
# cat deploy.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: udp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: default-http-backend
  labels:
    app: default-http-backend
  namespace: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: default-http-backend
  template:
    metadata:
      labels:
       app: default-http-backend
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: default-http-backend
        image:  registry.cn-qingdao.aliyuncs.com/kubernetes_xingej/defaultbackend-amd64:1.5      #建议提前在node节点下载镜像；
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
        ports:
        - containerPort: 8080
        resources:
         # 这里调整了cpu和memory的大小，可能不同集群限制的最小值不同，看部署失败的原因就清楚
          limits:
            cpu: 100m
            memory: 100Mi
          requests:
            cpu: 100m
            memory: 100Mi
---
apiVersion: v1
kind: Service
metadata:
  name: default-http-backend
  # namespace: ingress-nginx
  namespace: ingress-nginx
  labels:
    app: default-http-backend
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: default-http-backend
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: nginx-ingress-clusterrole
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
  - apiGroups:
      - "extensions"
      - "networking.k8s.io"
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "extensions"
      - "networking.k8s.io"
    resources:
      - ingresses/status
    verbs:
      - update
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-nginx"
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - get
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: nginx-ingress-role-nisa-binding
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress-role
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: nginx-ingress-clusterrole-nisa-binding
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress-clusterrole
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      # wait up to five minutes for the drain of connections
      terminationGracePeriodSeconds: 300
      serviceAccountName: nginx-ingress-serviceaccount
      nodeSelector:
        kubernetes.io/os: linux
      containers:
        - name: nginx-ingress-controller
          image: suisrc/ingress-nginx:0.30.0   #建议提前在node节点下载镜像；
          args:
            - /nginx-ingress-controller
            - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
          securityContext:
            allowPrivilegeEscalation: true
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE
            # www-data -> 101
            runAsUser: 101
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
            - name: https
              containerPort: 443
              protocol: TCP
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10
          lifecycle:
            preStop:
              exec:
                command:
                  - /wait-shutdown
---
apiVersion: v1
kind: LimitRange
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  limits:
  - min:
      memory: 90Mi
      cpu: 100m
    type: Container
---
apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  type: NodePort
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
      # HTTP
      nodePort: 80
    - name: https
      port: 443
      targetPort: 443
      protocol: TCP
     # HTTPS
      nodePort: 443
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx


1
2
3
注：
1.简单的来说，就是每个Node节点通过NodePort类型的Service绑定80端口，转发请求给我们的Ingress-Controller的Pod（类似于Nginx）, Ingress-Controller再根据域名规则转发给我们其他的Service的Pod,Ingress-Controller可以动态感知Ingress对象，读取Ingress对象的规则，生成一段Ngixn的转发规则配置
2.Ingress这段是参考网友博客的，感觉描述的很好就搬过来了，下面有原文地址

总结：

K8S Ingress = 微服务网关， 本质：七层反向代理，微服务集中出入口

1
2
3

cd 安装目录

展开全文 >>

K8s集群：标签和选择算符


K8s集群：标签和选择算符

一、k8s - label 介绍

label 介绍

官方：https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

label是 Kubernetes 系统中一个核心概念，很多功能都是基于绑定 Label来做选择。一个 Label 是 一个 key=value 的键值对，其中 key 与 value 由用户自己指定。Label 可以被 附加到各种资源对象上，例如 Node、Pod、Service、RC 等，一个资源对 象可以定义任意数量的 Label，同一个 Label 也可以被添加到任意数量的 资源对象上。Label 通常在资源对象定义时确定，也可以在对象创建后 动态添加或者删除。

label 是附加到 Kubernetes 对象（比如 Pods）上的键值对。 标签旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。 标签可以用于组织和选择对象的子集。标签可以在创建时附加到对象，随后可以随时添加和修改。 每个对象都可以定义一组键/值标签。每个键对于给定对象必须是唯一的。

我们可以通过给指定的资源对象捆绑一个或多个不同的 Label 来实 现多维度的资源分组管理功能，以便灵活、方便地进行资源分配、调 度、配置、部署等管理工作。例如，部署不同版本的应用到不同的环境 中;监控和分析应用(日志记录、监控、告警)等。一些常用的 Label 示例如下。

◎ 版本标签:”release”:”stable”

◎ 环境标 签:”environment”:”dev”、”environment”:”rc”

您可以指定自己项目中 Label的 Key ，请记住，标签的 Key 对于给定对象必须是唯一的

label 管理

创建 label

标签的格式是 <Key: Value> 格式，标签的 Key 对于给定的值必须是唯一的。

  • 命令式

    • 给名为 datarc 的 Pod 添加 label unhealthy=true

      kubectl label pods datarc unhealthy=true

  • yaml式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 以下是一个有 environment: production 和 app: nginx 标签的 Pod 配置文件：
# cat pod-nginx-label.yaml
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

kubectl apply -f pod-nginx-labels.yaml

kubectl get pods –show-labels

修改 label

  • 给名为 datarc 的 Pod 修改 label 为 'status' / value 'unhealthy' ，且覆盖现有的 value

    kubectl label –overwrite pods datarc status=unhealthy

  • 给 namespace 中的所有 Pod 添加 label

    kubectl label pods –all status=unhealthy

  • 给命名空间中 ns-datarc名为 datarc 的 Pod 添加 label app=datarc

    kubelctl -n ns-datarc label pods datarc app=datarc

删除 label

删除名为 app 的 label 。（使用“ - ”减号相连）

kubel label pods datarc app-

有效标签值：

  • 必须为 63 个字符或更少（可以为空）
  • 除非标签值为空，必须以字母数字字符（[a-z0-9A-Z]）开头和结尾
  • 包含破折号（-）、下划线（_）、点（.）和字母或数字

二、 Selector

Selector(标签选择器)：

label(标签)不具唯一性。一般来说，我们可以说许多对象可以带有相同的标签。标签选择器是 Kubernetes 中的核心分组。用户使用它们来选择一组对象。通过一个过滤的语法查找到对应标签的资源

一旦我们使用kubectl命令运行该文件，它将创建一个名为sp-nginx-standalone的服务，该服务将在8080端口上进行通信。type为NodePort，新的标签选择器为app: service和component: nginx。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 将 label 标签选择器用作 app: service ，将 component 组件用作 component: nginx ：
# cat pod-nginx-Selector.yaml
apiVersion: v1
kind: Service
metadata:
   name: sp-nginx-standalone
spec:
   ports:
      - port: 8080
      name: nginx
   type: NodePort
   selector:
      app: service
      component: nginx

展开全文 >>

K8s集群：命名空间（Namespace）


K8s集群：命名空间（Namespace）

一、k8s - namespace 介绍

命名空间

namespace 用于资源隔离，不同环境下的资源可以放置到同一个集群下不同的 namespace 下，如 dev、rc、demo 环境分别使用不同的 namespace。也可用不同的 namespace 区分客户。

命名空间用途

  • 名字空间适用于存在很多跨多个团队或项目的用户的场景。对于只有几到几十个用户的集群，根本不需要创建或考虑名字空间。当需要名称空间提供的功能时，请开始使用它们。

  • 名字空间为名称提供了一个范围。资源的名称需要在名字空间内是唯一的，但不能跨名字空间。 名字空间不能相互嵌套，每个 Kubernetes 资源只能在一个名字空间中。

  • 名字空间是在多个用户之间划分集群资源的一种方法。

  • namespace 还可以对 namespace 进行资源限制，如最多允许使用 cpu、内存、创建多少个 pod 等。

  • 不必使用多个名字空间来分隔仅仅轻微不同的资源，例如同一软件的不同版本： 应该使用标签来区分同一名字空间中的不同资源。

大多数的 K8s 集群中，默认会有几个 默认的 namespace。

1
2
3
4
5
6
root@jenkins:~# kubectl get ns
NAME              STATUS   AGE
default           Active   7d22h
kube-node-lease   Active   7d22h
kube-public       Active   7d22h
kube-system       Active   7d22h

  • default：你的service和app默认被创建于此。

  • kube-system：kubernetes系统组件使用。

  • kube-public：公共资源使用。但实际上现在并不常用。

  • kube-node-lease：此命名空间用于与各个节点相关的租期(Lease)对象；此对象的设计使得集群规模很大时节点心跳检测性能得到提升。

二、 namespace 管理

创建 namespace

注意：创建命名空间时，应避免使用 kube-作为前缀。因为它是为 Kubernetes 系统名字空间保留的。
  • 命令式

kubectl create namespace datarc

  • yaml 式
1
2
3
4
5
# cat my-datarc.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: datarc

kubectl apply -f my-datarc.yaml

查看 namespace

kubectl get ns

kubectl describe ns datarc # 查看详细信息

kubectl get pods -n datarc # 查看某个 namespace 下的资源

输出 namespace 为 json yaml 文件

kubectl get ns datarc -o <格式参数>

删除 namespace

删除namespace，其下的所有资源将全部被删除

kubectl delete namespaces datarc

三、在 namespace 创建资源

命令指定 namespace

1
2
3
4
5
6
7
8
9
10
11
# cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: mypod
  labels:
    name: mypod
spec:
  containers:
  - name: mypod
    image: nginx

kubectl apply -f pod.yaml –namespace=datarc

yaml 文件 指定资源的 namespace

1
2
3
4
5
6
7
8
9
10
11
12
# cat pod-datarc.yaml
apiVersion: v1
kind: Pod
metadata:
  name: mypod
  namespace: datarc
  labels:
    name: mypod
spec:
  containers:
  - name: mypod
    image: nginx

kubectl apply -f pod-datarc.yaml

目前 使用命令 kubectl get pods 查看您的 pod ，您会得到：资源未找到的错误。
这是因为命令是在当前（default）命名空间中，如果要查看其他 namespace 资源，你需要指定 namespace，如下所示：

kubectl get pods –namespace=datarc

四、 管理当前已经创建的 namespace

快捷使用 namespace

默认创建的命名空间是 default 。因此，当您在其他 namespace 创建了资源，那么每次使用 kubectl 命令都要带上 namespace 将会很麻烦。正好 kubens 可以解决这个麻烦。

安装 kubens

curl -L https://github.com/ahmetb/kubectx/releases/download/v0.9.4/kubens -o /bin/kubens
&& chmod +x /bin/kubens

使用 kubens

  • 当您运行 kubens 命令时，会自动高亮当前的 namespace：
  • 如果要切换 datarc 空间时，运行

kubens datarc

  • 这时后续执行的所有命令都会在 datarc 这个 namespace 下执行。

五、跨 namespace 通信

namespace 通信

命名空间彼此之间是互不通信的。但它们并不是绝对的相互隔绝。一个 namespace 中 service 可以和另一个 namespace 中的 service 通信。这在项目共享中非常有用，比如你项目的一个 service 要和另外一个项目的 service 通信，而你们的 service 都在各自的 namespace 中。

当你的节点要访问 Kubernetes 的 service ，你可以使用内置的 DNS 服务发现并把你的 节点 指到 Service 的名称。你可以在多个 namespace 中创建同名的 service 。解决这个问题，就用到 DNS 地址的扩展形式。
在 Kubernetes 中，Service 通过一个 DNS 模式来暴露 endpoint 。这个模式类似：

1
<Service Name>.<Namespace Name>.svc.cluster.local

一般情况下，你只需要service的名称，DNS会自动解析到它的全地址。然而，如果你要访问其他namespace中的service，那么你就需要同时使用service名称和namespace名称。例如，你想访问test中的“database”服务，你可以使用下面的地址：

database.test

六、建议约束

  • 在同一个命名空间中，资源名称须保持唯一。但在不同命名空间中，可以存在相同名称的资源。
  • 每一个资源只能隶属于一个命名空间。
  • 但命名空间本身不能属于另一个命名空间。

展开全文 >>

CI - Git


Git

整体流程

1
2
3
4
5
6
7
8
1. 注册公司的 gitea 账户
2. 项目管理员拉入团队
3. git clone 'url' 至本地，公钥管理仓库
4. git branch -b hcc-key
5. 增加自己的公钥
6. git add . 
7. git commit -m "chore: 增加 hcc 的 公钥"
8. git push origin hcc-key

当你开始新项目时

1
2
3
4
#1. 初始化新仓库
mkdir new-demo
git init					# 将当前目录作为 Git 本地仓库使用
git init [目录名]			  # 创建新目录，当作 Git 本地仓库使用
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#2. 设置签名
设置签名的作用是：区分不同开发人员的身份 ，这里设置的签名和登录远程库(代码托管中心)的账号、密码没有任何关系。
当前仓库有效：设置完信息保存位置：./.git/config 文件，可以通过cat查看

$ git config --local user.name "name"：设置用户名

$ git config --local user.email "email address"：设置邮箱

$ cat ./.git/config或者$ git config --local --list：查看配置结果

全局有效设置：设置完信息保存位置：~/.gitconfig可以通过cat查看

$ git config --global user.name "name"：设置用户名

$ git config --global user.email "email address"：设置邮箱

$ cat ~/.gitconfig或者$ git config --global --list：查看配置结果
1
2
#3. 状态查看
$ git status：查看工作区、暂存区状态
1
2
3
#4. 添加修改至暂存区
$ git add 文件名 ：将工作区的“新建/修改”文件添加到暂存区
$ git add .：将所有“新建/修改”文件添加到暂存区
1
2
#5. 提交本地库
$ git commit -m "注释" ：将暂存区的内容提交到本地库

分支管理

什么是分支？

在版本控制过程中，使用多条线同时推进多个任务。

分支的好处

  • 同时并行推进多个功能开发，提高开发效率
  • 各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响。失败的分支删除重新开始即可。

分支创建，切换，删除

  • git branch [分支名] ：创建分支

    • git branch -a：查看所有分支

  • git checkout [分支名]：切换分支

    • git checkout -b [分支名] ：创建并切换至新分支

  • git branch -D [分支名]：删除分支

分支合并

合并分支需要有两步操作

  • git checkout [被合并分支名]：切换到接受修改的分支（要被合并，增加新内容的分支）
  • git merge [要合并过来的分支名]：将另一个分支并入当前的分支中去。 Git 会自动以最佳方式将两个不同快照中独特的工作合并到一个新快照中去。

解决冲突

当两个要合并的分支同时修改到同一个文件的同一行时，执行合并操作的时候Git不知道到底保留哪一行是正确的，这个时候就会产生合并冲突，需要手动去修改。

当执行合并操作并且产生合并冲突时，需要手动去修改。

  • 编辑文件，删除特殊符号 <<<<<<< DEAD

  • 把文件修改到满意的程度，保存退出

  • git add [文件名]

  • git commit -m "日志信息"：（此时 commit 一定不能带具体文件名）

项目管理

不像中心化的版本控制系统（客户端与服务端很不一样），Git 仓库基本上都是一致的，并且并可以同步他们。 这使得拥有多个远端仓库变得容易 —— 你可以拥有一些只读的仓库，另外的一些也可写的仓库。

当你需要与远端仓库同步的时候，不需要使用它详细的链接。Git 储存了你感兴趣的远端仓库的链接的别名或者昵称。 你可以使用 git remote 命令管理这个远端仓库列表。

  • git remote ：列出远端名
  • git remote -v：列出每个远端名的实际链接地址
  • git remote add：为你的项目添加一个新仓库
    • git remote add [alias] [URL]
  • git remote rm ：删除现存的某个别名
    • git remote rm [alias]

Git项目分支设计
一个好的项目需要有一个合理的项目分支管理

  • master：主分支；经过本地测试的，开发分支，开发新功能的基准分支
  • rc：预发布分支；合并到master的测试分支，有bug就修复，然后合并回develop分支
  • stable：demo 分支，经过测试，给客户使用

分支与合并

  • branch
  • 分支创建，切换，删除
    • git branch [分支名] ：创建分支
    • git branch -D [分支名]：删除分支
    • git branch -a：查看分支
    • git checkout [分支名]：切换分支
    • git checkout -b [分支名] ：创建并切换至新分支

查看历史记录

下面四种方式都可以查看历史提交记录，$ git reflog这个指令较为常用，后面的版本切换一般都是使用这个命名查看即可。

  • git log：提交人，提交id，提交时间，提交描述等（多屏显示控制方式： 空格向下翻页 、b 向上翻页 、q 退出 ）
  • git log --author：之寻找某个作者的最近几次提交，大小写敏感
    • git log --author=[作者] --online -[几次]
  • git log --since --before：根据日期过滤提交记录
    • git log --oneline --before={3.weeks.ago} --after={2022-08-10} --no-merges ：Git 项目中三周前且在八月十日之后的所有提交
  • git log --pretty=oneline：简化版：提交ID，提交描述
  • git log --oneline：简化版：提交ID，提交描述
  • git reflog：简化版：提交ID，提交描述

比较文件差异

对比文件差异的方式有以下三种：

  • git diff [文件名]：将工作区中的文件和暂存区进行比较
  • git diff [本地库中历史版本] [文件名]：将工作区中的文件和本地库历史记录比较
  • git diff：不带文件名比较多个文件

历史版本前进后退

Git 会记录我们提交的各个信息，并由 HEAD 指针来指向最新的提交，版本前进和后退的本质就是移动指针来实现。

版本前进后退有以下三种方式可实现

  • git reset --hard 分支号：基于索引值操作[推荐] （7bf0e31再图4.1中查看）
  • git reset --hard HEAD^：使用^符号：只能后退 （一个^表示后退一步，n 个表示后退 n 步）
  • git reset --hard HEAD~n：使用~符号：只能后退 （表示后退 n 步 ）

reset 命令的3个参数

  • --soft 参数 ： 仅仅在本地库移动 HEAD 指针
  • --mixed 参数：在本地库移动 HEAD 指针，重置暂存区
  • --hard 参数 ：在本地库移动 HEAD 指针、重置暂存区、重置工作区

删除文件找回

找回文件分两种情况：

  • git reset –hard [指针位置]：删除操作已经提交到本地库

  • git reset –hard HEAD：删除操作尚未提交到本地库

HEAD就指向是本地库的当前提交版本位置，上面的操作，就是将工作区和暂存区与本地库同步。

git tag 给历史记录中的某个重要的一点打上标签

比如说，我们想为我们的项目发布一个 1.0 版本，我们可以用 git tag -a v1.0 命令给最新一次提交打上（HEAD）v1.0 的标签。

  • git tag -a [版本]：打 tag
    • git log --oneline --decorate --graph : 我们可以看到我们的标签和备注了

展开全文 >>

Linux 之 K8s 搭建


kubeadm工具初始化一套k8s集群

修改主机名

1
2
3
hostnamectl --static set-hostname <机器名 k8s101 k8s102 k8s103>

echo $(hostname -I | awk '{print $1}' ) $(hostname) >> /etc/hosts

允许iptables检查桥接流量

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# ubuntu
# 关闭防火墙

systemctl stop ufw && systemctl disable ufw

# 禁用交换分区(在旧版的 k8s 中 kubelet 都要求关闭 swapoff ，但最新版的 kubelet 其实已经支持 swap ，因此这一步其实可以不做。)
swapoff -a && swapoff -a && sed -i '/ swap / s/^/#/' /etc/fstab
# 修改内核参数(首先确认你的系统已经加载了 br_netfilter 模块，默认是没有该模块的，需要你先安装 bridge-utils)
apt-get install -y bridge-utils
modprobe br_netfilter
lsmod | grep br_netfilter
# 如果报错找不到包，需要先更新 apt-get update -y

# 允许 iptables 检查桥接流量
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF

sudo sysctl --system

安装 工具 与 Docker

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# ubuntu 安装
#step 1: 安装必要的一些系统工具
sudo apt-get update && sudo apt-get -y install apt-transport-https ca-certificates curl software-properties-common

#step 2: 安装GPG证书

curl -s https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | apt-key add -
tee /etc/apt/sources.list.d/kubernetes.list <<EOF 
deb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main
EOF
apt-get update && apt-get install docker.io -y

# 2. 配置Docker守护程序
# ubuntu:
mkdir /etc/docker
cat <<EOF | sudo tee /etc/docker/daemon.json
{
  "insecure-registries": ["k8s201:5000"],
  "registry-mirrors": ["https://tuv7rqqq.mirror.aliyuncs.com"],
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}
EOF

sudo systemctl enable docker && sudo systemctl daemon-reload && sudo systemctl restart docker

所有节点安装kubeadm软件包

1
2
# 安装k8s组件
apt-get install -y kubelet=1.23.6-00 kubeadm=1.23.6-00 kubectl=1.23.6-00 && systemctl enable kubelet && systemctl start kubelet

主节点使用kubeadm工具初始化一套k8s集群

1
kubeadm init --kubernetes-version=v1.23.0 --image-repository registry.aliyuncs.com/google_containers  --pod-network-cidr=10.244.0.0/16 --service-cidr=10.254.0.0/16

创建管理员证书文件

1
2
3
4
5
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

温馨提示:	当我们执行上述3条命令后，就可以正常管理集群啦！

node节点加入到现有集群

1
2
kubeadm join 10.3.22.144:6443 --token e8fxx6.mtldauwy3v5qfpox \
	--discovery-token-ca-cert-hash sha256:8d32dbfde18174cb887dfa721d382d00e3397dc6fe39011de9ef02d021cd48d3 
1
2
# 在主结点执行，查看 Node 如何 加入集群
kubeadm token create --print-join-command
1
2
3
4
5
6
7
8
9
10
11
# 踢出 Node 节点
(1)驱逐这个node节点上的pod	
（1 打污点的方式		
1）kubectl  	
（2 禁用node		
1）kubectl drain k8s155  --delete-local-data --force --ignore-daemonsets

(2)删除这个node节点kubectl delete node k8s155

(3)在node节点执行如下命令kubeadm reset -f温馨提示:	运行"kubeadm reset -f"可还原“kubeadm init”或“kubeadm join”对此主机所做的任何更改;
rm -rf  /etc/cni/net.d

​

部署flannel网络插件

1
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

部署 Dashbord 看板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
# 官方 https://github.com/kubernetes/dashboard 
# 要部署 Dashboard，请执行以下命令：
wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.6.1/aio/deploy/recommended.yaml

默认Dashboard只能集群内部访问，修改Service为NodePort类型，暴露到外部访问。找到Services配置。在配置文件上边。增加type:NodePort和 nodePort:30100端口

# service部分
默认Dashboard只能集群内部访问，修改Service为NodePort类型，暴露到外部访问。找到Services配置。在配置文件上边。增加type:NodePort和 nodePort:30100端口
kind: Service 
apiVersion: v1 
metadata: 
  labels: 
    k8s-app: kubernetes-dashboard 
  name: kubernetes-dashboard 
  namespace: kubernetes-dashboard 
spec: 
  ports: 
    - port: 443 
      targetPort: 8443 
      nodePort: 30001
  type: NodePort 
  selector: 
    k8s-app: kubernetes-dashboard
    

# 安装
kubectl apply -f recommended.yaml

# 获得 PORT 访问
kubectl get all -n kubernetes-dashboard -o wide 

# 游览器访问，https
https://69.230.207.162:30001/#/login

# 分步查看token信息
#1.根据命名空间找到我们创建的用户 
kubectl get sa -n kubernetes-dashboard 

#2.查看我们创建用户的详细信息。找到token属性对应的secret值 
kubectl describe sa dashboard-admin -n kubernetes-dashboard 
kubectl describe secrets dashboard-admin-token-9pl4b -n kubernetes-dashboard 

#3.或者是根据命名空间查找secrets。获得dashboard-admin用户的secret。 
kubectl get secrets -n kubernetes-dashboard 
kubectl describe secrets dashboard-admin-token-9pl4b -n kubernetes-dashboard


# 快速查看token信息   
kubectl -n kubernetes-dashboard describe secret $(kubectl -n kubernetes-dashboard get secret | grep dashboard-admin | awk '{print $1}')






# k8sdashboard出厂的serviceaccount权限太低，需要配置一个admin用户，用它的token登录即可
# 创建Service Account 与 ClusterRoleBinding
#cat dashboard-user-admin.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kubernetes-dashboard

---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kubernetes-dashboard
# 启动
kubectl apply -f dashboard-user-admin.yaml


# 获取 admin 的token 
kubectl -n kubernetes-dashboard get secret $(kubectl -n kubernetes-dashboard get sa/admin-user -o jsonpath="{.secrets[0].name}") -o go-template="{{.data.token | base64decode}}"

1
2
3
4
5
6
7
8
9
10
11
12
13
# 网络卡可提前下载
kubeadm config images list # 查看所需要的镜像列表

k8s.gcr.io/kube-apiserver:v1.23.6
k8s.gcr.io/kube-controller-manager:v1.23.6
k8s.gcr.io/kube-scheduler:v1.23.6
k8s.gcr.io/kube-proxy:v1.23.6
k8s.gcr.io/pause:3.6
k8s.gcr.io/etcd:3.5.1-0
k8s.gcr.io/coredns/coredns:v1.8.6

# 借助阿里镜像源
kubeadm config images pull --image-repository=registry.aliyuncs.com/google_containers
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
# 可能遇到的问题

# 删除最新的 kubeadm、kubelet、kubectl
yum remove -y kubeadm kubelet kubectl


# 可能遇到的问题

#1. error execution phase preflight: [preflight] Some fatal errors occurred:
	[ERROR CRI]: container runtime is not running: output: E0818 10:06:17.191489    4875 remote_runtime.go:925] "Status from runtime service failed" err="rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService"
time="2022-08-18T10:06:17+08:00" level=fatal msg="getting status of runtime: rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService"
, error: exit status 1


#解决方法：
rm -rf /etc/containerd/config.toml && systemctl restart containerd



# 可能遇到错误
# 1. k8s初始化报错
error execution phase preflight: [preflight] Some fatal errors occurred:
        [ERROR CRI]: container runtime is not running: output: E0725 08:28:43.725092   27421 remote_runtime.go:925] "Status from runtime service failed" err="rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService"
time="2022-08-25T08:28:43+08:00" level=fatal msg="getting status of runtime: rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService"
, error: exit status 1
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
To see the stack trace of this error execute with --v=5 or higher
#  解决方法
 rm -rf /etc/containerd/config.toml && systemctl restart containerd4

# 2. init 报错、需要重新 init 
 kubeadm reset && rm -rf  /etc/cni/net.d
 
 
 
 taint {node-role.kubernetes.io/master: }
 首先这个问题是由什么造成的：
当创建单机版的 k8s 时，这个时候 master 节点是默认不允许调度 pod 的，需要执行

kubectl taint nodes --all node-role.kubernetes.io/master-
命令将 master 标记为可调度.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: default-http-backend
  labels:
    app.kubernetes.io/name: default-http-backend
    app.kubernetes.io/part-of: ingress-nginx
  namespace: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: default-http-backend
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: default-http-backend
        app.kubernetes.io/part-of: ingress-nginx
    spec:
      terminationGracePeriodSeconds: 60
      containers:
        - name: default-http-backend
          # Any image is permissible as long as:
          # 1. It serves a 404 page at /
          # 2. It serves 200 on a /healthz endpoint
          image: registry.cn-qingdao.aliyuncs.com/kubernetes_xingej/defaultbackend-amd64:1.5
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
              scheme: HTTP
            initialDelaySeconds: 30
            timeoutSeconds: 5
          ports:
            - containerPort: 8080
          resources:
            limits:
              cpu: 10m
              memory: 20Mi
            requests:
              cpu: 10m
              memory: 20Mi
---
apiVersion: v1
kind: Service
metadata:
  name: default-http-backend
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: default-http-backend
    app.kubernetes.io/part-of: ingress-nginx
spec:
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app.kubernetes.io/name: default-http-backend
    app.kubernetes.io/part-of: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
data:
  proxy-body-size: "15m"
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: udp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: nginx-ingress-clusterrole
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "extensions"
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
  - apiGroups:
      - "extensions"
    resources:
      - ingresses/status
    verbs:
      - update
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-nginx"
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - get
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: nginx-ingress-role-nisa-binding
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress-role
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: nginx-ingress-clusterrole-nisa-binding
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress-clusterrole
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  # replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      hostNetwork: true
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller
          image: registry.cn-qingdao.aliyuncs.com/kubernetes_xingej/nginx-ingress-controller:0.20.0
          args:
            - /nginx-ingress-controller
            - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --annotations-prefix=nginx.ingress.kubernetes.io
          securityContext:
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE
            # www-data -> 33
            runAsUser: 33
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
            - name: http
              containerPort: 80
              hostPort: 80
            - name: https
              hostPort: 443
              containerPort: 443
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1

展开全文 >>

Linux之相关命令


Linux之相关命令

基础命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
1. ls 命令
   1）作用：列出目标目录中所有的子目录和文件，不包括.开头的文件
   2）格式
   	 （1）ls [选项] [路径/文件/目录]
   3）选项
   	 （1）-l 列出文件的详细信息
   	 （2）-a 列出文件的所有文件，包括.开头的文件
   	 （3）-A 和a一样，但不列出当前目录
   	 （4）-h 列出文件大小
   	 （5）-i 列出文件的inode号
   	 （6）-t 按时间进行文件排序
   	 （7）-R 递归显示目录下所有的内容
   	 （8）-r 反向排序
   4）案例
   	 （1）ls /home/cc
   	 	  #查看绝对路径下的文件
     （2）ls cc
     	  #查看相对路径下的文件
   	 （3）ls | sed "s#^#`pwd`/#"
		  #在ls中列出当前路径下的文件的绝对路径
1
2
3
4
5
6
7
8
9
10
11
12
2. cd 命令
	1）作用：用来切换工作目录至指定的目录
	2）格式
	  （1）cd [相对路径或绝对路径或特殊符号]
	3）选项
	  （1）相对路径
	  （2）绝对路径
	  （3）特殊符号
	4）案例
	  （1）cd ..
	  （2）cd /
	  （3）cd -
1
2
3
4
5
6
7
8
9
3. pwd 命令
	1）作用：显示当前用户当前工作目录的绝对路径
	2）格式
	  （1）pwd [选项]
	3）选项
	  （1）-L 打印当前目录，包括链接
	  （2）-P 打印当前目录的完整路径（实际物理地址）
	4）案例
	  （1）pwd 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
4. mkdir 命令
	1）作用：创建目录
	2）格式
	  （1）mkdir [选项][目录名]
	3）选项
	  （1）-p 创建多级目录，若中间不存在，可自动创建
	  （2）-m 创建目录时设置权限
	4）案例
	  （1）mkdir -p /h/c    
	  	  #相对路径创建h目录和c目录
	  （2）mkdir /home/h{1..5}
	  	  #绝对路径创建/home下的h1-h5目录
	  （3）mkdir /home/{h1,h2,h3}
	  	  #绝对路径创建/home下的h1、h2、h3目录
	  （4）mkdir -m 333 /h
	  	  #创建h目录并设置权限为333
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
5. touch 命令
	1）作用：创建文件
	2）格式；
	  （1）touch [选项] [文件名]
	3）选项：
	  （1）-a 只更改文件的最后访问时间
	4）案例
	  （1）touch h.txt
	  	  #相对路径创建h.txt
	  （2）touch /home/h.txt
      	  #绝对路径创建/home下的h.txt文件
      （3）touch /home/h1.txt /home/c1.txt
      	  #绝对路径创建/home下h1.txt和c1.txt
      （4）touch /home/h{1..5}.txt
      	  #绝对路径创建/home下的h开头的5个.txt文件
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
6. cp 命令
	1）作用：复制文件或目录
	2）格式：
	  （1）cp [选项] [源文件] [目标文件]
	3）选项：
	  （1）-r 递归复制，复制目录以下的所有目录和文件
	  （2）-a 功能总和
	  （3）-t 颠倒位置 [目标文件] [源文件]
	4）案例
	  （1）cp h.txt c.txt
	  	  #复制h.txt 并改名为c.txt
	  （2）\cp h.txt c.txt
      	  #复制h.txt 并改名为c.txt \不提示
	  （3）cp -r h1 h2
	  	  #复制h1文件夹及以下的文件到h2文件夹下，需要加-r
	  （4）cp /home/1 /tmp/2
	  	  #绝对路径复制/home下的1 复制到 /tmp下并改名为2
	  （5）cp /home/h1.txt{,.ori}	  
	  	  #快速备份文件
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
7. mv命令
	1）作用：移动文件或者重命名文件
	2）格式：
	  （1）mv [选项] [源文件] [目标文件]
	3）选项：
	  （1）-b 当目标文件和目录存在时，再覆盖前，会创建一个备份
	  （2）-i 当目标文件已经存在时，会询问是否覆盖
	  （3）-n 不要覆盖任何已经存在的文件或目录
	  （4）-t 指定mv的目标文件，移动多个源文件到一个目标目录，
	  		 目标文件在前，源文件在后
	4）案例
	  （1）mv h1.txt h6.txt
	  	  #当前位置移动就是重命名
	  （2）mv h1/h1.txt /h2/
      	  #移动/h1下的h1.txt 到/h2下
	  （3）mv h1/h1.txt /h2/h2.txt
	  	  #移动/h1下的h1.txt 到/h2下并改名为h2.txt
	  （4）mv -t /h1/{h1,h2} /h2/
	  	  #移动/h1下的h1，h2 到/h2下
1
2
3
4
5
6
7
8
9
10
11
12
13
8. rm命令
	1）作用：删除文件或目录
	2）格式：
	  （1）rm [选项] [文件或目标]
	3）选项：
	  （1）-i 删除前逐一询问确认
	  （2）-f 直接删除，无需确认
	  （3）-r 将目录下所有内容递归删除
	4）案例
	  （1）rm -rf 1,2
	  	  #删除本目录下的1,2文件，无需确认
	  （2）rm -rf /1.txt 2.txt h
      	  #删除多个文件，用空格隔开
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
9. echo命令
	1）作用：将指定文本输出到命令行
	2）格式：
	  （1）echo [选项] [文本]
	3）选项：
	  （1）-n 不自动换行，输出为1行
	  （2）-e 识别特殊字符
	4）案例
	  （1）echo hello 
	  	  #输出 hello 到命令行
	  （2）echo 'hello'
      	  #输出 hello 到命令行
	  （3）echo -e 'hello\tworld'
	  	  #输出hello 和world ，自动识别\t等特殊字符
	  （4）echo hello >> hello.txt
	  	  #输出hello到 hello.txt 的文本中
	  （5）echo ping baudi.com &>> hello.txt  
	  	  #不管输出结果正确还是失败都写入到 hello.txt  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
10. cat命令
	1）作用：连接多个文件并打印输出，或显示单个文件内容
	2）格式：
	  （1）cat [选项] [文件]
	3）选项：
	  （1）-n 对输出的内容按行显示
	  （2）-b 和-n作用一样，忽略显示空白行行号
	  （3）-A 三个功能总和
	  （4）-E 每行的行尾显示$符号
	4）案例
	  （1）cat 1.txt
	  	  #查看1.txt文件内的内容
	  （2）cat -n 1.txt
      	  #按行号打印1.txt文件
	  （3）cat -E 1.txt
	  	  #查看1.txt文件并在行尾添加$符号
	  （4）cat 1.txt 2.txt
	  	  #将1.txt 2.txt连接，并显示文件
	  （5）cat 1.txt 2.txt > 3.txt
	  	  #将1.txt和2.txt合并到3.txt中
	  （6）cat > ./1.txt <<EOF
	  	  user=hcc
	  	  hello ${user}!!!
	  	  EOF
	  	  # 将 hello hcc!!! 写入 1.txt
	  	 
       （7）cat > ./1.txt <<'EOF'
	  	  user=hcc
	  	  hello ${user}!!!
	  	  EOF
	  	  # 将 hello ${user}!!! 写入 1.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
11. tree命令
	1）作用：以树形结构列出目录下所有的内容
	2）格式：
	  （1）tree [选项] [目录]
	3）选项：
	  （1）-a 显示所有文件，包括隐藏文件
	  （2）-d 只显示目录
	  （3）-L 限制目录显示层级
	4）案例
	  （1）tree -L 2
	  	  #树形结构显示2层
	  （2）tree -d /home/cc
      	  #树形结构显示/home/cc下的目录
	  （3）tree -L 6 -d /home
	  	  #树形结构显示/home下的6层文件夹目录
1
2
3
4
5
6
7
8
9
10
11
12
13
12. more命令
	1）作用：将文件一页一页显示文件内容
	2）格式：
	  （1）more [选项] [文件]
	3）选项：
	  （1）-5 查看前5行
	  （2）+5 从第5行开始显示，指定行显示
	  （3）类似vim
	4）案例
	  （1）more -5 /etc/passwd
	  	  #查看前5行
	  （2）more +5 /etc/passwd
      	  #从第5行开始查看
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
13. less命令
	1）作用：分页显示文件内容
	2）格式：
	  （1）less [选项] [文件]
	3）选项：
	  （1）-i  忽略大小写
	  （2）-N  显示行号
	  （3）-m  显示进度条
	4）案例
	  （1）less /etc/passwd
	  	  #全部显示文件
	  （2）less -N /etc/passswd
      	  #按行号显示文件
	  （3）ls /etc/|less
	  	  #按照每页显示目录文件名
	  	  
	  	  less 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
14. head命令
	1）作用：显示头部命令，默认显示前10行
	2）格式：
	  （1）head [选项] [文件]
	3）选项：
	  （1）-5    指定显示行数 ，指定显示5行
	  （2）-c    指定显示字节数
	4）案例
	  （1）head -n 5 /etc/passwd
	  	  #显示前5行
	  （2）head /etc/passwd
      	  #显示前十行
	  （3）head -c 10 /etc/passwd
	  	  #显示前10个字节
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
15. tail命令
	1）作用：显示文件尾部的内容，默认显示后10行的内容
	2）格式：
	  （1）tail [命令] [文件]
	3）选项：
	  （1）-f 实时查看
	  （2）-n 5 指定显示的行数
	  （3）
	4）案例
	  （1）tail /etc/passwd
	  	  #显示文件后10行
	  （2）tailf /var/log/seoue  或者 tail -f
      	  #实时监控查看文件后10行的变化
	  （3）tail -5 /etc/passwd
	  	  #显示文件后5行
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
16. tr命令
	1）作用：从标准输入中替换，或删除字符，并将结果写在标准输出
	2）格式：
	  （1）tr [字符1] [字符2] [字符3]
	3）选项：
	  （1）-d    	删除字符
	  （2）-s		保留连续出现的第一个字符，删除其他字符，类似筛选去重
	  （3）-c     取反
	4）案例
	  （1）tr 'abc' 'hcc' < 1.txt
	  	  #将文中出现的abc 替换成 hcc 并输出到 1.txt
	  （2）tr '[a-z]' '[A-Z]' < 1.txt
      	  #将文中所有小写替换成大写并输出到1.txt
	  （3）tr '[a-z]' '[0-9]' < 1.txt
	  	  #将文中所有的小写字母换成0-9
	  （4）tr -d 'root' < 1.txt
	  	  #删除文中出现的root字符,凡是r、o、o、t出现的都算，而不是root
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
17. find命令
	1）作用：用于查找目录下的文件
	2）格式：
	  （1）find [选项] [路径] [操作语句] 
	  find    搜索路径      文件类型               选项           文件名
	  find      ./         -type                  d            hcc
	3）选项：
	  （1）-name  	根据名字查找   加i，不区分大小写-iname
	  （2）-size  	根据大小查找
	  （3）-user		根据用户名的所有者查找
	  （4）-type		根据文件类型查找（f文件，d目录，l软链接）
	  （5）-inum		根据文件inode查找
	  （6）-i         不区分大小写
	  （7）-mmin      按照最后时间   -mtime 按天
	  （8）!          取反
	  （9）-o         或者
	4）案例
	  （1）find /hh -size +1m   c字节小m大G
	  	  #在/hh中查找大于1m的文件
	  （2）find /hh -type f  
      	  #在/hh中查找所有f文件 f：普通文件
	  （3）find /hh -iname 'h*'
	  	  #在/hh中查找h开头的文件不区分大小写
	  （4）find /hh -iname 'h*' -ls
	  	  #在/hh中查找h开头的文件并显示详细信息 不区分大小写
	  （5）find /hh -type f -mmin -10
	  	  #在/hh中查找过去十分钟内更新的普通文件
按照关系查找：	  	  
		1.查找所有以 .txt 结尾 或以  stu 开头的普通文件
			find ./ -type f -name "*.txt" -or -name "stu*"
		2.查找所有以 .txt 结尾 并且 以 stu 开头的普通文件
			find ./ -type f -name "*.txt" -name "stu"

按照深度查找：
		1.按深度 1 查找 所有以txt结尾的文件
			find ./ -maxdepth 1 -name "*.txt"
		2.查找当前深度为1级 大于 2M 并且 小于 10M 的文件并显示文件大小
			find ./ -maxdepth 1 -size +2M -size -10M | xargs ls -lh
		3.查找当前深度为1级 名为 a.txt 或者 大小大于5M的文件
			find ./ -maxdepth 1 -name "a.txt" -or -size +5M
		4.查找当前深度为1级 名为 a.txt 大小为2M的文件
			find ./ -maxdepth 1 -name "a.txt" -size 2M

将find交给其他命令：
1. 将 find的 结果 结合xargs 交给  ls 
   - find ./ -type f | xargs ls -l
   - find ./ -type f | xargs cat -n
2. 使用``反引号 先执行反引号中的命令 将执行后的结果保留 其他命令调用
   - cat `` 
3. 使用esec 命令 两端有空格
   - find ./ -type f -exec cat {} \ ;
案例：
	1.将find 的结果 交给 rm
		1）find ./ -name    "1"    | xargs rm
		2）rm `find ./ -name "1"`
		3)find /hc/ -name cc | xargs rm -r
		4）find ./ -name "*.txt"     -exec rm {} \;
		5）\rm -d `find /root/hcc/ -type d -name "*.txt"` 删除目录
	2.将find 的结果 交给 cp
		1）find /etc/  -name "passwd" | xargs cp -t .
		2）find /etc/  -name "passwd" | xargs -i cp {} ./
		3）cp `find /etc/  -name "passwd"` .
		4）find /etc/ -name "passwd" -exec cp {} ./ \;
	3.将find 的结果 交给 mv
		1）find ./ -name passwd | xargs -i mv {} ./
		2）mv `find /etc/ -name "passwd"` /opt
		3）find ./ -name passwd   -exec    mv {} ./ \;
1
2
3
4
5
6
7
8
9
10
17. which命令
	1）作用：显示命令的全路径
	2）格式：
	  （1）which [选项] [命令名]
	3）选项：
	  （1）-a		遍历全部，搜索全部
	
	4）案例
	  （1）which pwd
	  	  #搜索pwd命令并显示全路径+
1
2
3
4
5
6
7
8
9
17. whereis命令
	1）作用：定位文件的可执行文件
	2）格式：
	  （1）whereis [选项] [文件名]
	3）选项：
	  （1）-b		查找可执行文件
	4）案例
	  （1）whereis svn
	  	  #查找svn6+可执行文件
1
2
17. xargs命令
	1）作用：复制文件或目录

展开全文 >>

Linux 之定时任务


定时任务

什么是定时任务

  • 在特定的时间做什么事情
  • 类似于闹钟
  • 备忘录提醒
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
1. Linux定时任务
	1）备份  打包 --------->发送到一台备份服务器
	   业务低谷期
    2）时间更新
    	ntpdate ntp1.aliyun.com

2. 定时任务分类
	crond 定时任务服务，企业中使用的定时任务
	atd   只运行一次，后面不允许
	anaccron 非7*24小时运行的服务器
	
3. 定时任务的服务 
	安装软件cronie
	默认安装好，并且加入开机自启
	查看是否安装软件包 rpm -qa  ql   qc ivh e

定时任务分类

  • 第一种：系统定时任务，类似国家的定时任务 国庆
  • 第二种：用户定时任务，类似于自己家 每天过国庆
  • 互不影响

定时任务的配置文件

  • 系统配置文件：

    /etc/crontab //重点

  • 用户的配置文件

    crontab -e //和下面一样

    vim /var/spool/cron/当前用户名

    //编辑配置文件，默认为空 —>

定时任务之日志切割

  • 什么是日志切割：

    ​ 服务运行得过程中产生日志

    ​ 分析日志，正确的，错误得，需要的数据

    ​ 分析日志的时候发现日志文件过大 5G

    ​ 对大的文件，对服务产生的日志，做日志切割

1
2
3
1. 把当前的日志移动走并以现在时间
	1）mv messages messages-`date +%F`
	2）把服务重启现在或者重启服务重新生成日志

系统定时任务使用

1
2
3
4
5
6
定时任务使用：
	1） vim /etc/crontab    查看系统定时器
	2） 使用root账户的 
		(1) crontab -e 								(2)	/var/spool/cron/root
	3) crontab -l 查看当前用户的定时任务
	4）chkconfig --list   查看运行级别状态 				systemctl status croud

运行中的日志

1
2
3
tailf /var/log/cron   //运行的日志文件
cat /etc/crontab    //PATH环境变量
crontab -l     //用户

日志实现

  • 时间 用户 命令 月和周选一个
* * * * *
分 时 日 月 周
0-59 0-23 1-31 1-12 1-7 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
什么时间做什么，再想想下一次在什么时候执行任务

案例1：每天得上午8.30  ，来学习上车

30 08 * * * root echo xuexi
 
第一步：写入到配置文件中
 	vim /etc/crontab
 	30 08 * * * root mkdir 定时任务
第二步：进行测试
 	时间写到最短
 	看日志  tailf /var/log/cron
 
 注意：
 	输出的内容到文件中，如果文件不加路径，默认到家目录
 
案例2 ： 每天晚上12点回家，回家开车
00 00 * * *  echo huijia

 注意：分钟执行按照整分执行
* 表示每 第一个表示每分钟
/ 表示间隔时间 表示每5分钟执行一次 */5 * * * *
- 表示区间， 表示1点到7点的整点执行 00 1-7 * * *
， 表示不连续的时间 每天1点3点10点15点执行 00 1,3,10,15 * * *
分 时 日 月 周9 
1
2
3
4
5
6
7
8
9
10
11
笔试题：
	1. 每天凌晨执行一个定时任务，  晚上12点表示00 00
		00 00 * * * root echo hehe
			
	2. 每天 23点 12点到7点 每小时的每分钟
       * 23,00-07 * * * root echo hehe
          
    3. 晚上11点 12点到早上7点的每小时执行一次
       00 23,00-07/1 * * * root echo hehe
        
总结： 时间的整点执行，而不是按当前时间来执行

用户的定时任务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
1. 查看定时任务出错时的路径
   （1）cat /var/spool/mail/root  
	执行定时任务会自动发送执行的过程到下面的文件中，排	 除定向到文件中的定时任务

定时任务：
	1. 定时任务前面加注释，给同事看
		被攻击后，迁移数据，需要重启
		
	2. 使用脚本代替命令运行
		超过两条以上的写入一个文本，执行文本
* * * * * sh 1.sh &>/dev/null 
		脚本就是命令的集合
		
	3. 直接在定时任务中%必须得转义使用\%  在脚本中正常
		
	4. 在执行脚本的时候前面使用bash和或sh
	* * * * * bash /se.sh
	或者给 x 权限
	5. 在定时任务中执行的命令和脚本的结果必须定向到空或者文件中
	   1） 企业案例：如果没有定向到空会导致磁盘得inode被占满而导致无法存储数据
		(1)在没有开启邮件的情况下，每执行一条定时任务，就会临时生成一个小文件    1个文件占用最少1个inode和1个block
	    (2)查看临时小文件 
		 ll /var/spool/postfix/maildrop
		(3)如何解决： 
*	       1> 把执行结果定向到空或者文件中 
				&> 文件
		   2> 定时删除小文件
		   3> 开启邮件，没有小文件生产
			systemctl staic postfix
		2） 邮件如果开启，执行一条定时任务就会发送一条邮件，执行某些命令就会发送一条邮件，占用系统资源
		所以在企业中，大部分服务器涉及不到邮件，需要关闭邮件服务
		systemctl stop postfix
		systemctl disable postfix
		
6.打包进入相对路径
每天凌晨1点把/etc/目录  打包备份到/tmp目录，并且要求每天备份名字不同


7. 输出的内容默认存储到家目录，最好使用绝对路径
	* * * * * awk '{print $1}' /var/log/nginx/access.log|sort -r|uniq -c &>> /data/count.txt
	
8. cat /var/spool/mail/root
	systemctl start postfix   开启邮件功能
	
9. 定时任务运行脚本的时候可以识别的PATH只有 /usr/bin	    和/bin
	例如:ntpdate命令的路径是/usr/sbin/
	which ntpdate
	
	解决方法1：
	修改变量：
	命令的执行过程：
	1.执行命令首先查找当前的路径是否有这个命令，
	echo $PATH    bash   
	
	解决方法2：
	在命令的全面加上全路径   
	/usr/bin       

每天创建一个 创建一个以ip地址命名的目录，每分钟


分时日月周
* 每
/ 间隔
- 区间
，间隔

%

变量 解释器  给执行权限  开启邮件和不开启邮件


排错：
	cat /var/spool/mail/root  执行定时任务会自动发送执行的过程到下面的文件中，排除定向到文件中的定时任务

用户和系统的定时任务区别：
	1. 用户的定时任务不需要执行用户
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
定时任务相关文件
	/etc/crontab
	/var/spool/mail/root
	/var/spool/crons/root
	/var/log/cron
	/etc/profile
	
定时任务配置方式：
	系统配置： vim /etc/crontab
	用户配置： vim /vat/spool/cron/root crontab -e
	查看用户配置 crontab -l
    
分  时  日  月  周    
  
* 表示每
*/ 表示间隔 整点间隔
- 表示时间的区间范围 13-18
,  表示时间的间隔

案例：每天凌晨执行一条命令
		用户定时任务书写方式
		00 00 * * * 执行的命令
		系统定时任务书写方式 需要加用户
		00 00 * * * 用户  可执行的命令
		
间隔5分种 做时间同步
PATH=/usr/bin:/bin:/usr/sbin
source /etc/profile
*/5 * * * * /usr/sbin/ntpdate ntp1.aliyun.com



定时任务的注意事项:
	1. 加注释
	2. 打包绝对路径
	3. 百分号需要转义，在脚本中不需要
	4. 结果定向到空   &>
	5. 路径问题，用户定时任务只识别 /usr/bin /bin
		1）使用全路径 
		2）修改PATH变量   source /etc/profile
		3）全路径
	6. 超过两条命令的写入脚本中
		执行脚本前面加sh
		如果不加sh，加权限

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
脚本1：
1. 每天创建一个 创建一个以ip地址命名的目录  每分钟

	变量放在/etc/profile  永久实现
	ip=`ipconfig eth0|awk 'NR==2{print $2}'`
	Time=`date +%F-%M`
	mkdir ${ip}-$Time
	
2. 每天创建一个 创建一个以ip地址命名的目录，并把/etc/目录打包压缩放在里面，保持每天的压缩包名字不同  精确到秒
1） 命令行测试

2） 命令写入脚本
	ip=`ipconfig eth0|awk 'NR==2{print $2}'`
	Time1=`date +%F-%M`
	Time2=`date +%F-%H-%M-%S`
	Dir=/ttttt/${ip}_${time1}
	mkdir -p $Dir
	cd /etc
	tar zcf $Dir/$Time2-tar.gz /hosts
3） 测试脚本
	sh tar.sh
4） 写入定时任务，每分钟测试脚本
	* * * * * sh tar.sh 
5） 写入定时任务


PATH="$PATH:/data/app/bin/"

展开全文 >>

Linux 之 Caddy


Caddy V2 介绍

Caddy 2 是一个强大的、企业级的、开源的 Web 服务器，具有用 Go 编写的自动 HTTPS。也是当前唯一默认自动使用 TLS 的 Web 服务器。 使用 Caddy 2 轻松部署和扩展 HTTPS 。（静态文件、反向代理、负载平衡等）。

在线安装 Caddy

1
2
3
4
5
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

编写 Caddy 文件 静态文件、后端负载均衡

vim /etc/caddy/Caddyfile

1
2
3
4
5
6
7
8
9
10
linuxnbg.com {
		encode gzip
        root * /code/linuxnbg/dm-blog/public
        file_server
        
        reverse_proxy /api/* {
        to  localhost:9000 localhost:3000
        lb_policy round_robin
  }
}

反向代理

1
2
3
gitea.linuxnbg.com {
    reverse_proxy localhost:3000
}

重定向至 其他域名 例如百度

1
2
3
baidu.linuxnbg.com {
	redir https://www.baidu.com
}

将 linuxnbg.com 重定向至 www.linuxnbg.com

1
2
3
4
5
6
7
8
linuxnbg.com {
		redir https://www.linuxnbg.com
}

www.linuxnbg.com {
        root * /code/linuxnbg/dm-blog/public
        file_server
}

将 linuxnbg.com 重定向至 linuxnbg.com

1
2
3
4
5
6
7
8
www.linuxnbg.com {
		redir https://linuxnbg.com
}

linuxnbg.com {
        root * /code/linuxnbg/dm-blog/public
        file_server
}

负载均衡示例

1
2
3
4
5
6
linuxnbg.com {
        reverse_proxy  {
        to  localhost:9000 localhost:3000
        lb_policy round_robin
        }
}
1
2
3
4
5
6
7
8
9
10
# lb_policy 参数
first：选取第一个可用的上游
random：随机选取一个可用的上游
least_conn：选取当前请求数最少的上游,这个比较适合长连接的场景
ip_hash：根据IP的Hash值选取一个固定的上游
random_choose ：随机选取2个或者更多个上游，然后再从中选择负载最小的，n通常为2
header：这个是根据请求头的Hash选取一个固定的上游，和 ip_hash 很像，只不过它是根据指定的请求头的值进行Hash，然后选取上游的。所以这里的用法是 header <request_header_name> ，要指定一个请求头。
uri_hash：这个也和 ip_hash 很像，只不过它是根据请求的URI进行Hash，然后选取一个上游。
round_robin：这个策略是循环迭代，挨个使用一个个上游，每个上游都可以被用到，轮着来。
cookie [ []] ：如果你理解了以上几个基于Hash的负载均衡策略，那么这个 cookie 的也会很好理解，其实它就是通过cookie的值的hash来选取一个上游。在这里 name 表示要获取cookie值的 name ，默认是 lb ， secret 是用于Hash的密钥，使用的是Hamc256算法

启动服务

systemctl enable caddy && systemctl start caddy

官网：V1 与 V2 区别
https://caddyserver.com/docs/v2-upgrade

Docker 使用：

参考：https://hub.docker.com/_/caddy

docker-compose：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
version: "3.7"

services:
  caddy:
    image: caddy:<version>
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - $PWD/Caddyfile:/etc/caddy/Caddyfile
      - $PWD/site:/srv
      - caddy_data:/data
      - caddy_config:/config

volumes:
  caddy_data:
    external: true
  caddy_config:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
version: "3.7"

services:
  caddy:
    image: caddy:<version>
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./site:/srv
      - ./caddy_data:/data
      - ./caddy_config:/config

数据目录不能被视为缓存。它的内容不是短暂的，也不是仅仅为了表演。Caddy 将 TLS 证书、私钥、OCSP 订书钉和其他必要信息存储到数据目录中。如果不了解其含义，则不应将其清除。

展开全文 >>

Linux 之文件


Linux之文件

文件权限

  1. 文件权限是赋予给用户
  2. 文件权限对应了用户能对文件做什么
  3. 文件权限对应了不同的用户
  4. 文件权限只能root用户修改
  5. 权限位为9位权限位，最高权限为rwx
  6. 三位为一组，每一组对应了不同的用户
权限 解释
rw- 前三位，表示用户的属主权限，主人可对文件做什么
r– 中三位，表述用户属组权限，组内用户可对文件做什么
r– 后三位，表示其他用户权限
rw-r–r– r=4 w=2 x=1 . 表示selinux防火墙开启
r 可读 w 可写 x 执行 -不允许 
1
2
3
4
5
6
7
8
文件权限就是9位权限位数字相加
rw-r--r--   

r(4)w(2)-(0)  r(4)--   r(4)-- 相加==644 文件默认

前三位相加：6  中三位：4  后三位：4

rwxr-xr-xr   目录默认：755    最高777

软链接与硬链接

  • 硬链接：

    1）硬链接类似于超市的门，多个硬链接相当于超市有多个门，从哪个门都可以进入超市，表示文件可以从多个入口都可以进入

    2）一个宝藏有多个藏宝图，硬链接的个数就是藏宝图的个数

    3）相同的inode号互为硬链接，删除一个相互不影响

1
2
3
4
5
6
7
8
9
10
11
12
13
1）创建硬链接
	ln 源文件 链接文件
	ln 文件名 硬链接名称
	ln 1.txt 2.txt

特点：
	1）inode号相同
	2）硬链接无法跨文件系统
	3）删除硬链接，不影响源文件
	4）删除所有的硬链接，文件才被删除（文件没有被调用）
	
作用：给重要文件做备份
ln /etc/paswd hard_link_passwd.txt

  • 软链接：

    1）软链接类似于win中的快捷方式

    2）软链接的inode号和源文件不同，是一个新文件

    3）软链接文件和源文件，存放着具体存储数据的指针指向

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
1）创建软链接
	ln 源文件 -s 链接文件
	ln 1.txt -s 2.txt
	
特点：
	1）软链接的inode不同，软链接存放着指针指向
	2）必须对已存在的文件做软链接
	3）软链接可以跨文件系统
	4）删除源文件，软链接失效，变成红底白字显示
	5）删除软链接不影响源文件
	6）目录可以做软链接
	7）创建的软链接包括硬链接都是普通文件，可以用rm删除
	8）软链接显示最高权限，但没有实际意义，还是看源文件		权限

作用：
	1.可以使用软链接方式处理磁盘不够用
	2.使用软链接方式进行代码上线和代码回滚

文件属主和属组

  1. 系统用户：系统识别用户，使用UID用户标识

    1）三类用户：

    用户 UID
    管理员 0 root，1.可以登录操作系统 2.管理数据 3.管理服务
    虚拟用户 1-999 程序系统中每个程序运行有一个用户来支持nologin
    普通用户 1000+ 提高系统安全创建的普通用户 自己创建

  2. 文件用户属主

    1）查看当前文件属于哪个用户

  3. 用户属组

    1）查看当前用户属于哪个组

    2）默认创建用户时，创建一个以自己的名字相同的组

    3）查看用户属于哪个组

    ​ id hcc

表示唯一 主组 附加组
uid=1000(hcc) gid=1000(hcc) groups=1000(hcc) 
1
2
3
4
1. 一个用户可以属于一个组，默认就是一个组
2. 一个用户可以属于多个组，hcc属于 1组 2组 3组
3. 多个用户可以属于一个组
4. 多个用户可以属于多个组

文件时间

  1. 文件时间类型三种，文件属性存在inode号中，不包括文件名

    Access: 2021-07-29 18:53:45.000000000 +0800 访问时间 cat less grep 如果访问后文件没有修改再次访问时间不变
    Modify: 2021-07-28 15:03:20.000000000 +0800 修改文件时间 修改里面的内容 注意echo 和vim的问题
    Change: 2021-07-30 08:57:44.282994555 +0800 改变文件属性时间 修改文件的属性

inode和block的诞生—盖楼

  1. 磁盘—盖楼买地皮，买多块地皮
  2. 磁盘的RAID—将多块磁盘虚拟的组合在一起
  3. 安装操作系统—盖楼
  4. 磁盘分区—按照自己的需求进行规划：写字楼，停车场
  5. 格式化—打扫卫生
  6. 创建文件系统—生成定量的inode和block（类似于装修风格）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
inode的特点：
	1）类似于书的目录
	2）存储文件的属性及block的具体指针指向
	3）创建一个文件最小占用一个inode和一个block
	4）一个inode默认大小256B
	5）一个inode可以被多个文件占用，相同的inode号互为硬链接
	6）文件名称存储在上级目录的block中

block的特点：
	1）具体存放数据的位置，类似于书的内容，从目录inode找到block内容
	2）创建一个文件最少占用1个inode和1个block
	3）默认的block大小4k，可以修改
	4）大文件占用多个block
	5）10K占用3个block
	6）读取磁盘数据I/O，输入输出的次数决定了磁盘的使用效率

查看inode和block

  1. ll -i //查看inode
  2. ll -h //查看block
  3. 存储数据必要的inode和block
1
2
3
4
5
6
7
8
1. 如果系统无法创建文件和存储数据检查inode和block
   数据过大占用一个inode和多个block
	1）什么情况下inode会满
		小文件过多会导致inode                                      被占满
	2）什么情况下block会满
		大文件过多会导致block被占满
	3）文件是否被真正的删除，进程被占用
		磁盘满了，但是删除了大文件，空间还是没释放

文件的读取过程

  1. 先找到文件名称—找到文件相应的inode
  2. 通过inode的属性和指针指向找到具体存放，数据的位置
  3. block中存储着所有文件和目录名称
1
2
3
4
5
6
7
8
9
10
1. 查找/hcc/1.txt过程
	1）先查找/的inode
	2）通过/的inode找到/的block
	3）通过/的block找到hcc目录名
	4）通过hcc的目录名找到了hcc的inode
	5）通过hcc的inode找到hcc的block
	6）通过hcc的block找到1.txt的文件名
	7）通过1.txt的文件名查找到1.txt的inode
	8）通过1.txt的inode找到1.txt的block
	9）通过1.txt的block找到1.txt的内容

如何让文件更加安全

1
2
3
4
5
6
7
8
9
10
11
12
13
1）把重要的文件进行保护
	-i   无敌的 只能看啥都没办法干
	-a   只能追加内容，其他干啥都不行，可以查看，给系统配置文件
2）给重要的文件做指纹验证
	1.使用md5校验来判断文件是否被修改，只要文件内容发生变化，md5就会随之变化
	2.语法结构	md5sum 文件名
	
第一步：使用md5生成校验码，针对文件和文件中的内容
		md5sum 1.txt
第二步：修改文件中的内容
		echo test >> 1.txt
第三步：重新做MD5校验，值会发生改变
		md5sum 1.txt

文件的指纹监控

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
1）批量指纹监控
	1.  md5sum 1.txt > result_md5.txt
	2.  cat result_md5.txt	
    针对文件进行检查 
	1.	md5sum -c check	
    2.	md5sum -c result_md5.txt
  
  -c做了两个操作：
  	1.首先检查源文件的MD5值
  	2.拿着源文件的MD5值和我们的result_MD5.txt 存储的MD5值进行对比
 
	修改源文件后再检查会检查失败，无法匹配,注意文件的路径问题
   1. echo hehe >> 1.txt
   2. md5sum -c result_md5.txt
  
2)一次性给多个文件做指纹监控
	1.	md5sum *.txt > md5.txt
	2.	md5sum -c md5.txt      //文件没有被修改，提示ok
	3.	find /root/test -type f |xargs md5sum > /opt/md5.txt         //使用find批量操作
	4.	md5sum -c /opt/md5.txt 
 
注意:
	1) 文件中校验文件的位置必须正确
	2) 文件内容如果不是自己修改的如何处理
		a. 快速恢复业务
		b. 把有问题的代码移动到/tmp目录，保留现场证据
		c. 找最新的备份文件，快速恢复业务，文件一定要备份
		d. 业务恢复后重新做md5校验
	3) 自己人修改
		a. 暂停定时任务
		b. 修改完成后，重新做md5校验，覆盖原来的校验的文件

		mkdir sunmou;chattr +a sunmou

改变文件属性

1
2
3
4
5
chattr +i 文件名/带路径的目录    不允许所有用户对这个文件进行删除
chattr +a 文件名/带路径的目录	只允许追加，不允许删除

chattr -i 文件名/带路径的目录
chattr -a 文件名/带路径的目录

修改文件属主和属组

  • chown 修改属主和属组，修改文件属于谁
  • 文件夹的属主大于文件的属主
  • 语法格式：chown [参数选项]用户名.组名称 文件/带路径的文件/目录
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
1. 修改hcc.txt的属主
	chown hcc hcc.txt
2. 修改hcc.txt的属组
	chown .hcc hcc.txt
3. 同时修改属主和属组
	chown root.root hcc.txt
4. 使用通配符批量修改属主和属组
	chown hcc.hcc test/*.txt
5. 递归授权，大R 批量修改目录及目录下所有的文件授权为普通用户
	chown -R hcc.hcc test/*
6. 查看test
	ll test/data/

案例：groupadd 创建组
1）创建uid为1100 允许登录  ，并且创建家目录，属于test组的stu01账号
	group hehe   //创建前，必须先创建组
	useradd -u 1100 -s /bin/bash -g hehe stu01

12 位 权限

系统如何知道我对文件有什么权限

  • 文件对应权限位 属主 属组 其他

    -rw-r–r–

  • 文件的最高权限 644

  • 目录的最高权限 755

  • ​ = 先清空原来权限，后重新授权

1
2
3
4
5
6
1. 你是谁
	1）whoami
2. 通过你是谁（当前用户名）来找对应的权限位
	2）-rw-r--r--     对于其他用户权限就是 r--
3. 通过权限位置来确定拥有的权限
	3）对应权限位其他用户 换算成数字表示 r-- 400

修改权限

  • 修改权限chmod

    1. 语法结构：

    ​ chmod ugo+x 文件/带路径的文件目录
    ​ u=user 属主 g=group属组 p=other 其他用户

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
1）使用ugo +- 方式进行授权

	案例1：给属主用添加X权限  
		（1） chmod u+x 1.txt
		 给属主取消权限
		（1） chmod u-x 1.txt
		
	案例2：给属主和属组添加x 权限
    	（1）chmod ug+x 1.txt
    	给属主属组取消r权限
    	（1）chmod ug-r 1.txt
    	
    案例3：授权三位权限同时添加rw权限
    	（1）chmod ugo+x 1.txt
    	 取消x权限
    	 （1）chmod ugo-x 1.txt
    	 
    案例4：授权三位权限同时添加rw权限
    	（1）chmod a=r 1.txt //先清空后授权	 
   	
    案例5：取消所有位权限
    	chmod -rwx 1.txt
    	
2）使用ugo=方式进行授权
    chmod ugo+x
    chmod ugo-x
    chmod u=r
    chmod ugo=rw
    chmod +r
    chmod -rwx
    	 
1
2
3
4
5
6
7
8
9
10
使用数字授权
语法格式：
	chmod 777 文件/带路径的文件/目录

案例1：授权属主rwx 属组r-x  其他用户 r-- 换成754
	chmod 754 1.txt

案例2：授权一个文件为644权限对应的字符 rw-r--r--
	chmod 644 1.txt

权限对于文件的作用

  • 无法删除文件，对于文件来讲不决定文件是否可删除
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
1) r对文件的作用 read可读
特点：
	1.可读
	2.vim 可写入，但是会提示警告信息，使用wq！
	3.不能使用echo追加，不能sed写入
	4.全路径无法执行，涉及到脚本加bash
	5.无法删除文件，对于文件来讲不决定文件是否可删除

总结：r权限只能看

2）w对于文件的作用 write写入
特点：
	1.不能看，不能vim、less、sed、cat
	2.可以追加内容，只能 echo >> 
	3.不能执行

总结：w权限，只能echo追加

3）x对于文件的作用 excute执行
特点：
	1.不能读取文件
	2.不能写入

总结：x权限，一无是处
1
2
3
4
总结：文件权限rwx
	1. 如果正常查看只要r权限
	2. 如果正常写入必须rw配合使用
	3. 如果正常执行必须rx配合使用

权限对于目录的作用

  • 对于目录，rwx的作用
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
1）r对于目录的作用
特点：
	1.不能cd进入
	2.查看只能查看文件名称，不能查看详细信息
	3.不能创建文件目录等
	4.不能写内容到目录下的文件内
	5.不能删除

总结：r对于目录，只能看文件名
	
2）w对于目录的作用
特点：
	1.不能进入目录
	2.不能查看
	3.不能创建目录
	4.不能删除
	
总结：w对于目录，一无是处

3）x对于目录的作用
特点：
	1.可以进入目录
	2.不能查看
	3.不能创建
	4.不能删除
	5.不能写入
	
总结：x对于目录，只能进入目录
1
2
3
4
总结：=rwx对于目录：
	1. 单独使用啥也不能干
	2. rx 配合使用，可以进入目录，只能查看文件的内容，但是取决于文件属性,不能对文件做改变操作
	3. 想要在目录下正常操作，必须rwx权限
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[hcc@lzy hcc]$ cat /etc/shadow
cat: /etc/shadow: Permission denied

没有r
[hcc@lzy hcc]$ echo '#' >> /etc/passwd
-bash: /etc/passwd: Permission denied
文件没有w


[hcc@lzy hcc]$ touch /etc/passwd.txt
touch: cannot touch ‘/etc/passwd.txt’: Permission denied
文件没有w


[hcc@lzy hcc]$ rm -rf /etc/shadow
rm: cannot remove ‘/etc/shadow’: Permission denied
没 w或x


[hcc@lzy hcc]$ ls /root/
ls: cannot open directory /root/: Permission denied
没r

网站权限

  • 网站必须普通用户d的身份执行

    useradd -M www

    chown www.www 1.txt //将代码文件属主属组修改为www用户

    上传上来，没有执行权限，上传上来文件无法运行

  • 网布不能root的身份运行

  • 企业中：文件644 目录755

  • 777：高风险

Linux的默认权限

  • UMASK 控制linux创建目录和文件的权限，022
  • 默认创建的目录 755
  • 默认创建的文件 644
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
1） 查看UMASK
	umask

2） 创建文件默认权限
	公式：文件最大的权限减去UMASK默认值等于创建文件的权限
	文件最大权限：  默认UMASK  
	    666     -   022   =     644
	    
3） 创建目录默认权限
	公式：目录最大的权限减去UMASK默认值等于创建文件的权限
	目录最大权限：  默认UMASK  
	    777   -  022      =     755
	    
4） 修改默认UMASK 临时修改
	  umask 044
	  
注意事项：
	如果有奇数位，不影响目录，文件要在奇数位+1
	
案例： 创建一个文件默认位000 目录默认111 umask多少
		umask 666

文件的隐藏属性

1
2
3
4
5
6
7
8
9
10
11
12
1. 查看文件的隐藏属性
	1) lsattr 1.txt

2. 常用的隐藏属性
	a   只能追加内容，不能删除，不能修改，append
	i   只能查看，啥也不能干
	
3. 修改隐藏属性，添加a
	1) chattr +a 1.txt
    
4. 删除隐藏属性
	2) chattr -a 1.txt

特殊权限 第12位权限
s 属主 4
g 属组 2
t 其他用户 1 
1
2
3
4
5
6
1） s 作用：所有用户执行某个命令时，权限暂时为root
	chmod u+s /usr/bin/rm
	
2） t 作用：粘滞位，来创建回收站，自己管理自己文件，	不能控制其他人文件
	chmod o+t test
	chmod o-t test
1
2
stat 1.txt
查看文件的详细信息

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

很惭愧，做了一些微小的工作