kdc配置HA
1 机器
Kdc主节点:k8s-01
kdc从节点:k8s-02
2 主节点修改
2.1 主节点修改配置
/etc/krb5.conf
[realms]
TONGDUN.COM = {
kdc = k8s-01
kdc = k8s-02
…(如果有多从kdc,一行一个)
admin_server = k8s-01
}
2.2 添加principal
kadmin.local
addprinc -randkey host/k8s-01
addprinc -randkey host/k8s-02
//将主、从节点的princ整合到krb5.keytab中
ktadd -k /etc/krb5.keytab host/k8s-01
ktadd -k /etc/krb5.keytab host/k8s-02
3 从节点搭建
从节点安装参考《KDC服务安装及配置》
3.1 将master上配置同步到从节点
将master几个配置拷贝到从服务器:文件: krb5.conf、kdc.conf、kadmin5.acl、master key stash file
scp /etc/krb5.conf root@k8s-02:/etc
scp /etc/krb5.keytab root@k8s-02:/etc
scp /usr/local/krb5/var/krb5kdc/kdc.conf root@k8s-02:/usr/local/krb5/var/krb5kdc/
scp /usr/local/krb5/var/krb5kdc/kadm5.acl root@k8s-02:/usr/local/krb5/var/krb5kdc/
scp /usr/local/krb5/var/krb5kdc/.k5.TONGDUN.COM root@k8s-02:/usr/local/krb5/var/krb5kdc/
3.2 创建Kerberos数据库(密码要和主节点保持一致,否则会报错)
kdb5_util
create -r your_realm -s,注意,在Loading random data这里的时候可能会要比较久的时间
[root@ip-172-31-6-148 ~]# kdb5_util create –r TONGDUN.COM -s
Loading random data
4 从节点启动kpropd进程
kpropd -S
5 在slave上添加/usr/local/krb5/var/krb5kdc/kpropd.acl
cat > /usr/local/krb5/var/krb5kdc/kpropd.acl << EOF
host/k8s-01@TONGDUN.COM
host/k8s-02@TONGDUN.COM
EOF
6 同步数据至slave db (主节点上执行)
主节点dump库信息:
kdb5_util dump /var/kerberos/krb5kdc/slave_data
将库信息拷贝至从节点:
scp /usr/local/krb5/var/krb5kdc/slave_data /usr/local/krb5/var/krb5kdc/slave_data.dump_ok k8s-02:/usr/local/krb5/var/krb5kdc/
让从主机加载主库信息(从库会被整库覆盖)
kprop -f /usr/local/krb5/var/krb5kdc/slave_data k8s-02
成功:提示:Database propagation to k8s-02: SUCCEEDED
注意:hostname一定要单一。从日志中能看出来。
7 启动从节点kdc
krb5kdc
8 多从节点数据同步样例
如果多个从节点,定期自动进行主、从库同步,脚本示例 如有两个从kdc:dp200和dp201,在主kdc节点上定期执行如下脚本:
#!/bin/sh
kdclist = "dp200 dp201"
kdb5_util dump /usr/local/krb5/var/krb5kdc/slave_data
for kdc in $kdclist
do
scp slave_data slave_data.dump_ok $kdc:/usr/local/krb5/var/krb5kdc/
scp /etc/krb5.keytab $kdc:/etc/
kprop -f /usr/local/krb5/var/krb5kdc/slave_data $kdc
done
9 客户端搭建
将/etc/krb5.conf拷贝至所有客户端主机的/etc下。
10 测试
关闭主kdc服务,在客户端机器执行已有账号的kinit登录,可以正常登录。即说明ha生效了。
另外,kdc的ha是根据krb5.conf中配置kdc的顺序决定的,客户端按配置顺序挨个发请求,第一个kdc能访问则不会向后面的kdc服务发请求(即:master不是绑定死的)
如果第一个kdc请求不通,则再依次向后面kdc发请求。 如果第一个kdc再起起来,则下次请求还是会访问第一个kdc(可以从kdc日志中看出来)