发表于 | 分类于 ， | | 热度: ℃
字数统计: 720 字 | 阅读时长 ≈ 4 分钟

问题简述

原本用kubeadm安装的的kubernetes 1.11.x集群升级到1.12.x 后（使用kubeadm upgrade升级）发现无法将新的node加入到集群中，会出现以下报错信息

1
2
3
4
5
6
7
8
9
10
11
12
13
[preflight] running pre-flight checks
    [WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_sh ip_vs ip_vs_rr ip_vs_wrr] or no builtin kernel ipvs support: map[ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{} ip_vs:{}]
you can solve this problem with following methods:
 1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "172.19.170.254:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://172.19.170.254:6443"
[discovery] Requesting info from "https://172.19.170.254:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "172.19.170.254:6443"
[discovery] Successfully established connection with API Server "172.19.170.254:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
configmaps "kubelet-config-1.12" is forbidden: User "system:bootstrap:y1zgt7" cannot get configmaps in the namespace "kube-system"
阅读全文 »

发表于 | 分类于 ， | | 热度: ℃
字数统计: 792 字 | 阅读时长 ≈ 4 分钟

kubeadm部署的kubernets证书一直都是个诟病，默认都只有一年有效期，kubeadm 1.14.x安装后有部分证书还是一年有效期，但个别证书已修改为10年有效期，但对我们使用来说，一年有效期还是一个比较的坑，需要进行调整。

修改kubeadm 1.14.x源码，调整证书过期时间

kubeadm1.14.x 安装过后crt证书如下所示

1
2
3
4
5
6
7
8
9
10
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/front-proxy-ca.crt         #10年有效期
/etc/kubernetes/pki/ca.crt                     #10年有效期
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/front-proxy-client.crt     #10年有效期
/etc/kubernetes/pki/etcd/server.crt
/etc/kubernetes/pki/etcd/ca.crt                #10年有效期
/etc/kubernetes/pki/etcd/peer.crt              #10年有效期
/etc/kubernetes/pki/etcd/healthcheck-client.crt
/etc/kubernetes/pki/apiserver-kubelet-client.crt
阅读全文 »

发表于 | 分类于 ， | | 热度: ℃
字数统计: 3,537 字 | 阅读时长 ≈ 15 分钟

前言

我们可以通过 Service 生成的ClusterIP(VIP)来访问 Pod 提供的服务，但是在使用的时候还有一个问题：我们怎么知道某个应用的 VIP 呢？比如我们有两个应用，一个是 api 应用，一个是 db 应用，两个应用都是通过Deployment进行管理的，并且都通过 Service 暴露出了端口提供服务。api 需要连接到 db 这个应用，我们只知道 db 应用的名称和 db 对应的 Service 的名称，但是并不知道它的 VIP 地址，我们前面的 Service 课程中是不是学习到我们通过ClusterIP就可以访问到后面的Pod服务，如果我们知道了 VIP 的地址是不是就行了？

apiserver

我们知道可以从 apiserver 中直接查询获取到对应 service 的后端 Endpoints信息，所以最简单的办法是从 apiserver 中直接查询，如果偶尔一个特殊的应用，我们通过apiserver去查询到Service后面的 Endpoints直接使用是没问题的，但是如果每个应用都在启动的时候去查询依赖的服务，这不但增加了应用的复杂度，这也导致了我们的应用需要依赖Kubernetes了，耦合度太高了，不具有通用性。

阅读全文 »

发表于 | 分类于 ， | | 热度: ℃
字数统计: 8,657 字 | 阅读时长 ≈ 45 分钟

常用操作命令

常规命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 设置主机名
hostnamectl --static set-hostname  xxxx

# 获取集群加入信息
kubeadm token create --print-join-command

# 设置docker仓库口令
kubectl create secret docker-registry registry-secret --docker-server=registry.cn-shanghai.aliyuncs.com --docker-username=xupeng@patsnap --docker-password=patsnap2019! --docker-email=xupeng@patsnap -n ningbo

# etcd3.3 node状态查看
ETCDCTL_API=3 etcdctl endpoint health --endpoints "https://10.40.20.41:2379,https://10.40.20.46:2379,https://10.40.20.233:2379"   --cacert=/etc/etcd/ssl/etcd-ca.pem  --cert=/etc/etcd/ssl/etcd.pem   --key=/etc/etcd/ssl/etcd-key.pem

# etcd key 查看
ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert /etc/kubernetes/pki/etcd/ca.crt \
--cert /etc/kubernetes/pki/etcd/peer.crt \
--key /etc/kubernetes/pki/etcd/peer.key \
get /registry/minions/ningbo-db --prefix
阅读全文 »