作者： 清朝云

共计 2844 个字符，预计需要花费 8 分钟才能阅读完成。

kubernetes 开发了一个基于web的用户界面（Dashboard）。用户可以使用Dashboard部署容器化的应用，还可以监控应用的状态，执行故障排查以及管理kubernetes中各种资源。

本次安装的环境：k8s 集群版本为 v1.25，dashboard 的版本是 v2.7.0。

1. 下载 yaml 文件

wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

2. 修改 Service

这一步主要是为了暴露 dashboard 服务端口。

kind: Service
apiVersion: v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kubernetes-dashboard
spec:
  type: NodePort  # 新增
  ports:
    - port: 443
      targetPort: 8443
      nodePort: 30010  # 新增
  selector:
    k8s-app: kubernetes-dashboard

修改 Service 类型为 NodePort 类型，然后指定端口为 30010。

3. 创建 dashboard

# 创建
kubectl apply -f recommended.yaml
# 查看 pod 状态
kubectl get pod -n kubernetes-dashboard

4. 创建用户

创建一个 dashboard-admin 用户，并绑定角色 cluster-admin，用以获取登录的 token。

# 创建 dashboard-admin 用户
kubectl create serviceaccount dashboard-admin -n kubernetes-dashboard
# 绑定 clusterrolebinding
kubectl create clusterrolebinding dashboard-admin-rb --clusterrole=cluster-admin --serviceaccount=kubernetes-dashboard:dashboard-admin

5. 创建 token

在以前版本的 kubernetes 中，进行了创建 serviceaccount 会自动生成一个 Secret 里面存放 token 值，但是新版本不会这样做了。可以参考之前的文章 k8s 手动管理 ServiceAccount 的 Secret。

# dashboard-admin-token.yaml
cat > dashboard-admin-token.yaml<<EOF
kind: Secret
metadata:
  name: dashboard-admin-secret
  namespace: kubernetes-dashboard
  annotations:
    kubernetes.io/service-account.name: dashboard-admin
type: kubernetes.io/service-account-token
EOF
# 创建 token
kubectl apply -f dashboard-admin-token.yaml

6. 获取 token 登录页面

[root@master sa]# kubectl describe secret dashboard-admin-secret -n kubernetes-dashboard
Name:         dashboard-admin-secret
Namespace:    kubernetes-dashboard
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: dashboard-admin
              kubernetes.io/service-account.uid: 86a0f643-c6e5-44a3-93f1-cd28aa090be9

Type:  kubernetes.io/service-account-token

Data
====
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IlJlaHp4U0syRTJzSWYzcnlxV2NXX0NCWUhpampSWjU4bjdtdG1yeXBuX3cifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkYXNoYm9hcmQtYWRtaW4tc2VjcmV0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImRhc2hib2FyZC1hZG1pbiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6Ijg2YTBmNjQzLWM2ZTUtNDRhMy05M2YxLWNkMjhhYTA5MGJlOSIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDprdWJlcm5ldGVzLWRhc2hib2FyZDpkYXNoYm9hcmQtYWRtaW4ifQ.kwMoelHZYpo8-S27-LhfcA75kwUj_xRE7hN2bshfMcyo8X1VvHoq7UQ_qk97NwFXMSF93wzdfcr0mVn12czaQkYxlLcdE6YVNNl8wcUq21YPMJmrwxj2yCR5fPUqh_2zAUJcVNlSbis3MCO_TiN3t5ljVMyWpeBXYbcxd7Sh_wcGNmgi6jb1u_7lnZL1XOd2jq9Wm2QupqQKtF_s-U80RIYE20g8pR-Qz9u65W-bU__khtIkJGMsWuyLUN-G8Jnx90ypXs3a18CaAfdaH6SVOJcWTnRisX1QhlUnP4OsO8cQ40r1gUWmDYQJr-mqBJ_MaYjBA5XnTm9ABtO5FIu36Q
ca.crt:     1070 bytes
namespace:  20 bytes

访问 https://任一节点ip:30010 端口，将 token 填写进行登录即可，页面如图所示：

/>

/>

7. 简单使用 dashboard

登录面板以后，可以很方便的集群的各种资源如 pod、deployment、configmap 等进行查看。同时，提供了多种创建资源的方式。

/>

接下来用表单创建一个 nginx 的 deploy。

/>

可以看见已经创建完成。

提醒：本文发布于796天前，文中所关联的信息可能已发生改变，请知悉！

/>

共计 1700 个字符，预计需要花费 5 分钟才能阅读完成。

什么是 serviceAccount

顾名思义，相对于userAccount（比如：kubectl访问APIServer时用的就是userAccount），serviceAccount 就是 Pod 中的 Process 用于访问 Kubernetes API的 account，它为 Pod 中的进程提供了一种身份标识。相比于 userAccount 的全局性权限，serviceAccount 更适合一些轻量级的task，更聚焦于授权给某些特定Pod中的Process所使用。

serviceAccount 并不复杂，只是关联了一个 Secret 资源作为 token，该token也叫service-account-token。

任意一个 pod 如果在不指定 serviceAccount 的情况下，都是用的默认的 serviceAccount。相关内容在容器的 /run/secrets/kubernetes.io/serviceaccount 目录下。该目录下有三个文件：ca.crt，namespace，token。

• ca.crt 用来验证 APIServer 的证书，因为证书都是自己生成的，所以需要创建集群 CA 证书进行验证。
• namespace 是该 pod 所在命名空间。
• token 是容器访问 APIServer 认证和授权所使用的内容，请求时放在 Authorization。

接下来创建 serviceAccount 并进行权限的测试。

serviceAccount 实战

1. 创建账号和角色

sa-pod-reader.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader
  namespace: dev

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-role
  namespace: dev
rules:
  - apiGroups: [""] # 支持的API组列表，""空字符串，表示核心API群
    resources: ["pods"] # 支持的资源对象列表
    verbs: ["get","watch","list"]

---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: authorization-role-binding
  namespace: dev
subjects:
  - kind: ServiceAccount
    name: pod-reader
roleRef:
  kind: Role
  name: pod-role
  apiGroup: rbac.authorization.k8s.io

# 创建用户和角色
kubectl apply -f sa-pod-reader.yaml

创建一个 pod-reader 的角色并和账号 pod-reader 进行绑定，pod-reader 的权限仅限于 dev 命名空间下 pod 的查询。

2. 创建 pod-reader 的 token

在以前版本的 kubernetes 中，进行了创建 serviceaccount 会自动生成一个 Secret 里面存放 token 值，但是新版本不会这样做了。可以参考之前的文章 k8s 手动管理 ServiceAccount 的 Secret。

pod-reader-token.yaml

apiVersion: v1
kind: Secret
metadata:
  name: pod-reader
  namespace: dev
  annotations:
    kubernetes.io/service-account.name: pod-reader
type: kubernetes.io/service-account-token

# 创建 secret
kubectl apply -f pod-reader-token.yaml

3. 测试权限

kubectl describe secret pod-reader -n dev

获取到 token 以后，使用 postman 进行测试。

设置 token。

/>

3.1 获取 dev 下的 pod

/>

可以看见能够进行获取。

3.2 获取 default 下的 pod

/>

提示没有权限，至此，测试完毕。

提醒：本文发布于795天前，文中所关联的信息可能已发生改变，请知悉！

共计 4062 个字符，预计需要花费 11 分钟才能阅读完成。

一、cfssl 是什么

清朝云在看很多视频的时候都看见过 cfssl 这个工具，所有抽时间了解了下。

在实际的工作中经常遇到制作自定义的服务器证书的场景，目前能够制作 CA 根证书及服务器证书有 openssl 及 cfssl 两种常用工具，之前介绍过 openssl 的 v3版 ssl 证书制作和 nginx 配置证书。

下面了解一下 cfssl 和它的使用。

cfssl 是 CloudFlare 开源的一款 PKI/TLS 工具。 cfssl 包含一个命令行工具 和一个用于签名，验证并且捆绑TLS证书的 HTTP API 服务。 使用Go语言编写。（目前常被用做 k8s 集群生成证书）

/>

二、安装 cfssl

1. 直接安装

• 下载安装

curl -s -L -o /usr/bin/cfssl https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 && \
curl -s -L -o /usr/bin/cfssljson https://pkg.cfssl.org/R1.2/ cfssljson_linux-amd64 && \
curl -s -L -o /usr/bin/cfssl-certinfo https://pkg.cfssl.org/R1.2/ cfssl-certinfo_linux-amd64 && \
chmod +x /bin/cfssl*

• 从 docker 容器拷贝

cat > entrypoint.sh<<EOF
#!/bin/sh
tail -f /dev/null
EOF
chmod +x entrypoint.sh
docker run -d --name cfssl -v $PWD:/workdir --entrypoint "/workdir/entrypoint.sh" cfssl/cfssl && \
docker cp cfssl:/usr/bin/cfssl . && \
docker cp cfssl:/usr/bin/cfssljson . && \
docker cp cfssl:/usr/bin/cfssl-certinfo . && \
mv cfssl* /usr/bin

2. docker 安装

docker pull cfssl/cfssl

docker 安装方式与直接安装不同的是使用方式不同。

cfssl/cfssl 镜像使用 /workdir 作为工作目录，为了使用方便可以使用宿主机当前目录映射到 /workdir。所以说需要的文件都应放在当前目录下，过程生成的文件也会输出在当前目录。

例如：docker run --rm -v $PWD:/workdir cfssl/cfssl certinfo -cert ca.crt，ca.crt 证书文件需要放在当前目录下，否则提示没有这个文件。

三、cfssl 命令

使用 cfssl --help 可以看见 cfssl 工具的相关命令。

version # 查看 cfssl 版本
selfsign # 生成一个新的自签名密钥和签名证书
certinfo # 输出给定证书的证书信息， 跟 cfssl-certinfo 工具作用一样
print-defaults # 打印json格式的模板-ca签名配置文件和客户端证书请求文件
  # config：生成ca配置模板文件
  # csr：生成证书请求模板文件
gencert # 生成新的key(密钥)和签名证书
  # -initca：初始化一个新ca （默认false，需要指定ca证书用以前面其他证书）
  # -ca：ca的证书
  # -ca-key：ca的私钥文件
  # -config：请求证书的json文件
  # -profile：与-config中的profile对应，是指根据config中的profile段来生成证书的相关信息
sign # 签名一个客户端证书，通过给定的CA和CA密钥，和主机名
revoke # 吊销证书
info # 获取签名者信息
bundle # 创建包含客户端证书的证书包
serve # 启动一个HTTP API服务
genkey  # 生成一个key(私钥)和csr(证书签名请求)
gencsr # 生成新的证书请求文件
gencrl # 生成新的证书吊销列表

1. cfssl selfsign

用于生成一个自签名证书，即自己颁发给自己的证书。

提示自签名证书很危险，使用此自签名证书风险自负，强烈建议不要使用这些证书在生产中。

# 1. 生成证书请求文件
cat > server-csr.json<<EOF
{
    "CN":"www.qcyqq.com",
    "hosts":[
        "127.0.0.1",
        "192.168.1.1",
        "qcyqq.com",
        "www.qcyqq.com"
    ],
    "key":{
        "algo":"rsa",
        "size":2048
    },
    "names":[
        {
            "OU":"iot",
            "O":"unipower",
            "ST":"GuangZhou",
            "L":"GuangDong",
            "C":"CN"
        }
    ]
}
EOF

# 2. 生成私钥和证书
# 使用方式 cfssl selfsign HOSTNAME CSRJSON
cfssl selfsign www.qcyqq.com server-csr.json | cfssljson -bare  server
# docker方式：
docker run --rm -v $PWD:/workdir cfssl/cfssl selfsign www.qcyqq.com server-csr.json | cfssljson -bare server

# 3. 查看证书
cfssl certinfo -cert server.pem

2. cfssl gencert

使用证书请求文件生成证书。

2.1 生成 CA 证书

与自签名证书类似，生成 CA 证书也需要证书请求文件。

# 1. 生成证书请求文件
cat > ca-csr.json <<EOF
{
    "CN":"kubernetes",
    "key":{
        "algo":"rsa",
        "size":2048
    },
    "names":[
        {
            "C":"CN",
            "L":"Hebei",
            "ST":"Zhangjiakou",
            "O":"k8s",
            "OU":"System"
        }
    ]
}
EOF

# 2. 生成证书
# -initca 指定这个生成 ca 证书，否则需要指定 ca 证书
cfssl gencert -initca ca-csr.json | cfssljson -bare ca
# docker方式：
docker run --rm -v $PWD:/workdir cfssl/cfssl gencert -initca ca-csr.json | cfssljson -bare ca

2.2 生成 CA 签名的证书

# 1. 生成证书配置文件（CA 进行签名时需要的配置）
cat > ca-config.json <<EOF
{
    "signing":{
        "default":{
            "expiry":"87600h"
        },
        "profiles":{
            "kubernetes":{
                "expiry":"87600h",
                "usages":[
                    "signing",
                    "key encipherment",
                    "server auth",
                    "client auth"
                ]
            }
        }
    }
}
EOF
# 这个策略，有一个默认的配置，和一个profile，可以设置多个profile，这里的profile是etcd。
# 默认策略，指定了证书的有效期是一年(8760h)
# etcd策略，指定了证书的用途
# signing, 表示该证书可用于签名其它证书；生成的 ca.pem 证书中 CA=TRUE
# server auth：表示 client 可以用该 CA 对 server 提供的证书进行验证
# client auth：表示 server 可以用该 CA 对 client 提供的证书进行验证

# 2. 生成服务端证书请求文件
cat > server-csr.json <<EOF
{
    "CN":"server",
    "hosts":[
        "127.0.0.1",
        "192.168.0.211",
        "192.168.0.212",
        "192.168.0.213",
        "10.10.10.1",
        "kubernetes",
        "kubernetes.default",
        "kubernetes.default.svc",
        "kubernetes.default.svc.cluster",
        "kubernetes.default.svc.cluste.local"
    ],
    "key":{
        "algo":"rsa",
        "size":2048
    },
    "names":[
        {
            "C":"CN",
            "L":"Hebei",
            "ST":"Zhangjiakou",
            "O":"k8s",
            "OU":"System"
        }
    ]
}
EOF

# 3. 基于之前生成的ca证书生成证书
cfssl gencert \
-ca=ca.pem \
-ca-key=ca-key.pem \
-config=ca-config.json \
-profile=kubernetes \
server-csr.json | cfssljson -bare server
# docker方式：
docker run --rm -v $PWD:/workdir cfssl/cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes server-csr.json | cfssljson -bare server

# 3. 查看证书
cfssl certinfo -cert server.pem

常用的就上面两个命令，基本满足日常使用

下面讲讲其他的命令，有部分是前面的命令的其中一步。比如，下面cfssl genkey 就是只生成 key 文件和证书请求文件，并不会生成证书。

3. cfssl genkey

# 1. 生成证书配置文件
cat > ca-config.json <<EOF
{
    "signing":{
        "default":{
            "expiry":"87600h"
        },
        "profiles":{
            "kubernetes":{
                "expiry":"87600h",
                "usages":[
                    "signing",
                    "key encipherment",
                    "server auth",
                    "client auth"
                ]
            }
        }
    }
}
EOF

# 2. 生成密钥文件
cfssl genkey ca-config.json | cfssljson -bare ca

提醒：本文发布于790天前，文中所关联的信息可能已发生改变，请知悉！

共计 5021 个字符，预计需要花费 13 分钟才能阅读完成。

一、Keepalived 简介

Keepalived 是 Linux 下一个轻量级别的高可用解决方案。高可用(High Avalilability,HA)，其实两种不同的含义：广义来讲，是指整个系统的高可用行，狭义的来讲就是之主机的冗余和接管，

它与 HeartBeat RoseHA 实现相同类似的功能，都可以实现服务或者网络的高可用，但是又有差别，HeartBeat 是一个专业的、功能完善的高可用软件，它提供了HA 软件所需的基本功能，比如：心跳检测、资源接管，检测集群中的服务，在集群节点转移共享IP地址的所有者等等。HeartBeat功能强大，但是部署和使用相对比较麻烦，

与 HeartBeat 相比，Keepalived 主要是通过虚拟路由冗余来实现高可用功能，虽然它没有 HeartBeat 功能强大，但是 Keepalived 部署和使用非常的简单，所有配置只需要一个配置文件即可以完成。

Keepalived 的高可用通过虚拟ip（vip）来实现，虚拟 ip 可以漂移。

/>

二、Keepalived 配置文件

global_defs {                                     #全局定义部分
    notification_email {                          #设置报警邮件地址，可设置多个
        acassen@firewall.loc                      #接收通知的邮件地址
    }
    notification_email_from test0@163.com         #设置 发送邮件通知的地址
    smtp_server smtp.163.com                      #设置 smtp server 地址，可是ip或域名.可选端口号 （默认25）
    smtp_connect_timeout 30                       #设置 连接 smtp server的超时时间
    router_id LVS_DEVEL                           #主机标识，用于邮件通知
    vrrp_skip_check_adv_addr
    vrrp_strict                                   #严格执行VRRP协议规范，此模式不支持节点单播
    vrrp_garp_interval 0
    vrrp_gna_interval 0
    script_user keepalived_script                 #指定运行脚本的用户名和组。默认使用用户的默认组。如未指定，默认为keepalived_script 用户，如无此用户，则使用root
    enable_script_security                        #如果路径为非root可写，不要配置脚本为root用户执行。
}

vrrp_script chk_nginx_service {                   #VRRP 脚本声明
    script "/etc/keepalived/chk_nginx.sh"         #周期性执行的脚本
    interval 3                                    #运行脚本的间隔时间，秒
    weight -20                                    #权重，priority值减去此值要小于备服务的priority值
    fall 3                                        #检测几次失败才为失败，整数
    rise 2                                        #检测几次状态为正常的，才确认正常，整数
    user keepalived_script                        #执行脚本的用户或组
}

vrrp_instance VI_1 {                              #vrrp 实例部分定义，VI_1自定义名称
    state MASTER                                  #指定 keepalived 的角色，必须大写 可选值：MASTER|BACKUP
    interface ens33                               #网卡设置，lvs需要绑定在网卡上，realserver绑定在回环口。区别：lvs对访问为外，realserver为内不易暴露本机信息
    virtual_router_id 51                          #虚拟路由标识，是一个数字，同一个vrrp 实例使用唯一的标识，MASTER和BACKUP 的 同一个 vrrp_instance 下 这个标识必须保持一致
    priority 100                                  #定义优先级，数字越大，优先级越高。
    advert_int 1                                  #设定 MASTER 与 BACKUP 负载均衡之间同步检查的时间间隔，单位为秒，两个节点设置必须一样
    authentication {                              #设置验证类型和密码，两个节点必须一致
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {                           #设置虚拟IP地址，可以设置多个虚拟IP地址，每行一个
        192.168.119.130
    }
    track_script {                                #脚本监控状态
        chk_nginx_service                         #可加权重，但会覆盖声明的脚本权重值。chk_nginx_service weight -20
    }
    notify_master "/etc/keepalived/start_haproxy.sh start"  #当前节点成为master时，通知脚本执行任务
    notify_backup "/etc/keepalived/start_haproxy.sh stop"   #当前节点成为backup时，通知脚本执行任务
    notify_fault  "/etc/keepalived/start_haproxy.sh stop"   #当当前节点出现故障，执行的任务;
}

## 虚拟服务器virtual_server定义块 ，虚拟服务器定义是keepalived框架最重要的项目了，是keepalived.conf必不可少的部分。 该部分是用来管理LVS的，是实现keepalive和LVS相结合的模块。
virtual_server 192.168.119.130 80  {          #定义RealServer对应的VIP及服务端口，IP和端口之间用空格隔开
    delay_loop 6                              #每隔6秒查询realserver状态
    lb_algo rr                                #后端调试算法（load balancing algorithm）
    lb_kind DR                                #LVS调度类型NAT/DR/TUN
    #persistence_timeout 60                   同一IP的连接60秒内被分配到同一台realserver
    protocol TCP                              #用TCP协议检查realserver状态
    real_server 192.168.119.120 80 {
        weight 1                              #权重，最大越高，lvs就越优先访问
        TCP_CHECK {                           #keepalived的健康检查方式HTTP_GET | SSL_GET | TCP_CHECK | SMTP_CHECK | MISC
            connect_timeout 10                #10秒无响应超时
            retry 3                           #重连次数3次
            delay_before_retry 3              #重连间隔时间
            connect_port 80                   #健康检查realserver的端口
        }
    }
    real_server 192.168.119.121 80 {
        weight 1                              #权重，最大越高，lvs就越优先访问
        TCP_CHECK {                           #keepalived的健康检查方式HTTP_GET | SSL_GET | TCP_CHECK | SMTP_CHECK | MISC
            connect_timeout 10                #10秒无响应超时
            retry 3                           #重连次数3次
            delay_before_retry 3              #重连间隔时间
            connect_port 80                   #健康检查realserver的端口
        }
    }
}

二、Keepalived 搭建

节点	网卡	主备节点	Vip
172.21.9.203	eth0	主节点	172.21.9.251
172.21.9.202	eth0	备用节点	172.21.9.251

1. 简单搭建

1.1 主节点搭建

docker run -d \
--name keepalived-master \
--net=host \
-e KEEPALIVED_INTERFACE="eth0" \
-e KEEPALIVED_PRIORITY=100 \
-e KEEPALIVED_UNICAST_PEERS="#PYTHON2BASH:['172.21.9.203', '172.21.9.202']" \
-e KEEPALIVED_VIRTUAL_IPS="172.21.9.251" \
-e KEEPALIVED_STATE="MASTER" \
--privileged=true \
osixia/keepalived --loglevel debug

1.2 备用节点搭建

docker run -d \
--name keepalived-backup \
--net=host \
-e KEEPALIVED_PRIORITY=50 \
-e KEEPALIVED_UNICAST_PEERS="#PYTHON2BASH:['172.21.9.203', '172.21.9.202']" \
-e KEEPALIVED_VIRTUAL_IPS="172.21.9.251" \
-e KEEPALIVED_STATE="BACKUP" \
--privileged=true \
osixia/keepalived --loglevel debug

2. 创建配置文件搭建

2.1 主节点搭建

# 1. 创建配置文件
mkdir -p /home/docker/keepalived/conf/ && \
cat > /home/docker/keepalived/conf/my-keepalived.conf<<EOF
global_defs {
  default_interface eth0
}

vrrp_instance VI_1 {
  interface eth0

  state MASTER
  virtual_router_id 51
  priority 100
  nopreempt

  unicast_peer {
    172.21.9.203
    172.21.9.202
  }

  virtual_ipaddress {
    172.21.9.251
  }

  authentication {
    auth_type PASS
    auth_pass d0cker
  }

  notify "/container/service/keepalived/assets/notify.sh"
}
EOF

# 2. docker启动
docker run -d \
--name keepalived-master \
-v /home/docker/keepalived/conf/keepalived.conf:/container/service/keepalived/assets/keepalived.conf \
--net=host \
--privileged=true \
osixia/keepalived --loglevel debug --copy-service

使用 ip a 命令，发现 eth0 网卡多了个 ip。

/>

2.2 备用节点搭建

# 1. 创建配置文件
mkdir -p /home/docker/keepalived/conf/ && \
cat > /home/docker/keepalived/conf/keepalived.conf<<EOF
lobal_defs {
  default_interface eth0
}

vrrp_instance VI_1 {
  interface eth0

  state BACKUP
  virtual_router_id 51
  priority 50
  nopreempt

  unicast_peer {
    172.21.9.203
    172.21.9.202
  }

  virtual_ipaddress {
    172.21.9.251
  }

  authentication {
    auth_type PASS
    auth_pass d0cker
  }

  notify "/container/service/keepalived/assets/notify.sh"
}
EOF

# 2. docker启动
docker run -d \
--name keepalived-backup \
-v /home/docker/keepalived/conf/keepalived.conf:/container/service/keepalived/assets/keepalived.conf \
--net=host \
--privileged=true \
osixia/keepalived --loglevel debug --copy-service

此时通过 ip a 命令查看，发现并没有 vip。

/>

3. 故障模拟

通过在主节点上模拟 keepalived 故障，使用命令 docker stop keepalived-master，可以看见 vip 漂移到备用节点。

/>

在主节点上再次模拟故障恢复，使用命令 docker stop keepalived-master，发现 vip 再次漂移到主节点

此时如果两台机器上都有 nginx，那么此时就可以通过虚拟节点来访问了，并可以通过 nginx 负载均衡到业务服务上。

三、其他说明

• 镜像说明

osixia/keepalived 镜像的源码地址：docker-keepalived

• vip 不释放问题

如果出现两个节点都存在 vip ，且程序退出后都不自动释放 vip，使用命令 ip addr del 172.21.9.251/32 dev eth0 进行删除。

提醒：本文发布于788天前，文中所关联的信息可能已发生改变，请知悉！

共计 992 个字符，预计需要花费 3 分钟才能阅读完成。

前提

XFS 是 centos7 预装的操作系统，XFS 只能扩大不能缩小。所以需要利用 xfsdump 、xfsrestore 工具在必须缩小 lvm 的情况下，备份与还原资料。即将其他目录备份后，然后进行一个缩容和格式化，然后再进行还原。

由于是使用 centos 系统，基本都是使用 root 用户操作，但是 centos 默认给根目录分配得较小，home 目录空间比较大。本教程的效果是缩减 /dev/mapper/centos-home的空间 ，将 home 分出来的空间分给/dev/mapper/centos-root。

/>

一、安装 xfsdump

安装 xfsdump 对 xfs 文件系统进行备份和还原。

yum -y install xfsdump

二、备份 home 目录

注意点：

• 根目录有足够大的空间存放备份文件，否则无法进行目录备份。
• 需要使用home目录的程序需要停止（比如home目录下有 docker 的映射目录，且此时程序不断在写入日志等数据）,否则会导致目录卸载，非常麻烦。

# 备份/home目录，备份在根目录下，也可以备份在其他目录下
xfsdump -f /home.xfsdump /home

会有两个地方提示让你输入说明，都可以随意填写，比如填写 home。

please enter label for this dump session (timeout in 300 sec)
please enter label for media in drive 0

三、缩减 lv-/dev/mapper/centos-home

# 卸载/home
umount /home

# 缩减 /dev/mapper/centos-home 为40G
lvreduce -L 40G /dev/mapper/centos-home

四、增加 lv-/dev/mapper/centos-root

# 扩展 lv，指定扩展空间为所有的空余空间，也可以是固定值如果 +50G
lvextend -l +100%FREE /dev/centos/root

# 延展 xfs 空间
xfs_growfs /dev/centos/root

五、还原 home 目录

# 格式化 home 的 lvm
mkfs.xfs -f /dev/mapper/centos-home

# 挂载 /home
mount /dev/mapper/centos-home /home

# 还原备份资料到 /home
xfsrestore -f /home.xfsdump /home

然后就可以把刚刚关掉的程序启动起来了。

提醒：本文发布于783天前，文中所关联的信息可能已发生改变，请知悉！

共计 1392 个字符，预计需要花费 4 分钟才能阅读完成。

简介

Fail2ban 通过扫描系统日志文件，例如 /var/log/pwdfail or /var/log/apache/error_log 并从中找出多次尝试登录失败的 IP 地址，并将该 IP 地址加入防火墙的拒绝访问列表中。它通过更新系统的防火墙规则，拒绝来自这些 IP 地址的新连接。Fail2Ban 开箱即用，可以读取许多标准的日志文件，如 sshd 和 Apache 的日志文件，也可以轻松配置为读取任何你选择的日志文件。

一、创建配置文件

注意：

1. 文件内不能有中文，否则会加载配置失败

2. 如果修改过端口号，则设置 port = 端口号

mkdir -p /home/docker/fail2ban/data/jail.d && \
cat >  /home/docker/fail2ban/data/jail.d/sshd.conf <<EOF
[sshd]
enabled = true
chain = INPUT
port = ssh
filter = sshd[mode=aggressive]
logpath = /var/log/secure
maxretry = 3
bantime = 3600
findtime = 600
EOF

配置说明：

enabled ：是否开启检测
port：检查的端口
maxretry：最大失败次数, 在检查时间内达到次数就拦截
bantime：拦截后禁止访问的时间，单位：秒
findtime：检查的时间访问，单位：秒
logpath: 扫描的日志文件，fail2ban按行扫描此文件，根据filter规则匹配失败的项目并统计

二、启动 fail2ban

docker run -d \
--name fail2ban \
--network host \
--cap-add NET_ADMIN \
--cap-add NET_RAW \
-v /home/docker/fail2ban/data:/data \
-v /var/log:/var/log:ro \
-e TZ=Asia/Shanghai \
--restart always \
crazymax/fail2ban:latest

三、相关命令

一个配置规则可以称为一个监狱，例如上面的 sshd 规则就是一个监狱。

1. 查看 fail2ban 状态

可以查看到 fail2ban 当前配置了哪些监狱。

docker exec -it fail2ban fail2ban-client status

2. 检验特定监狱的状态（如 sshd）

查看当前监狱的情况，如被封禁的 ip 列表和总数等。

docker exec -it fail2ban fail2ban-client status sshd

3. 手动封禁 ip

手动封禁 ip，使其不能与监狱配置的特定端口进行连接。

docker exec -it fail2ban fail2ban-client set sshd banip <ip>

4. 手动解禁 ip

docker exec -it fail2ban fail2ban-client set sshd unbanip <ip>

5. 查看防火墙配置

docker exec -it fail2ban iptables -nvL

四、结果

使用 fail2ban 之前，一天不到有接近 2000 次的尝试暴力破解。

/>

使用之后，几天不登录也不到 1000 次暴力破解。

/>

当然这并不能代表什么，但是可以作为一个对 ssh 基础保护的参考，更为保险的当然是修改 ssh 的端口号和设置更安全的密码。

虽然清朝云的密码自认为已经足够安全，但是不免出现了密码泄露的情况，所以导致了服务器被入侵的情况。

提醒：本文发布于778天前，文中所关联的信息可能已发生改变，请知悉！

/>