云原生知识星球
0%

发表于 更新于 分类于 阅读时长 ≈ 1 分钟

问题背景

K8S集群环境中有个容器化的组件A需要在节点上创建iptables规则实现请求转换，在centos 7的操作系统上功能正常，但在redhat 8的操作系统上发现该功能失效。具体来说，就是容器内iptables命令执行后没有生效。

分析过程

业务组件A的功能是基于iptables命令的，查看当前容器内使用的iptables版本：

1
2
~ # iptables -V
iptables v1.6.2

查看使用的centos 7宿主机上的iptables版本：

1
2
[root@node1 ~]# iptables -V
iptables v1.4.21

对比redhat8.4的环境，发现它提供的iptables版本较高，且模式从默认的legacy变成了nf_tables：

1
2
[root@node1 ~]# iptables -V
iptables v1.8.4 (nf_tables)

从redhat官方资料看[1]，该模式无法修改，因为在制作rpm包时删掉了legacy模式依赖的二进制文件：

阅读全文 »

发表于 更新于 分类于 阅读时长 ≈ 3 分钟

问题背景

K8S集群环境稳定运行一年后，pod重启卡在ContainerCreating状态：

1
2
3
4
5
6
7
8
[root@node1 ~]# kubectl get pod -n kube-system -owide
NAME                                      READY   STATUS    RESTARTS   AGE    IP                NODE    
calico-kube-controllers-cd96b6c89-bpjp6   1/1     Running   	   0          40h    10.10.0.1     node3
calico-node-ffsz8                         1/1     Running   	   0          14s    10.10.0.1     node3
calico-node-nsmwl                         1/1     Running   	   0          14s    10.10.0.2     node2
calico-node-w4ngt                         1/1     Running   	   0          14s    10.10.0.1     node1
coredns-55c8f5fd88-hw76t                  1/1     Running		   1          260d   192.168.135.55    node3
xxx-55c8f5fd88-vqwbz                      1/1     ContainerCreating 1          319d   192.168.104.22    node2

分析过程

describe查看

1
2
3
4
5
6
7
[root@node1 ~]# kubectl describe pod -n xxx xxx
Events:
  Type     Reason                  Age                 From               Message
  ----     ------                  ----                ----               -------
  Normal   Scheduled               52m                 default-scheduler  Successfully assigned xxx/xxx to node1
  Warning  FailedCreatePodSandBox  52m                 kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = [failed to set up sandbox container "xxx" network for pod "xxx": networkPlugin cni failed to set up pod "xxx" network: connection is unauthorized: Unauthorized, failed to clean up sandbox container "xxx" network for pod "xxx": networkPlugin cni failed to teardown pod "xxx" network: error getting ClusterInformation: connection is unauthorized: Unauthorized]
  Normal   SandboxChanged          50m (x10 over 52m)  kubelet            Pod sandbox changed, it will be killed and re-created.

事件里显示的Unauthorized，也就是因为无权限从kube-apiserver中获取相关信息，查看对应pod使用的token，发现确实存在过期时间相关的定义：

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
{
 alg: "RS256",
 kid: "nuXGyK2zjFNBRnO1ayeOxJDm_luMf4eqQFnqJbsVl7I"
}.
{
 aud: [
  "https://kubernetes.default.svc.cluster.local"
 ],
 exp: 1703086264, // 时间过期的定义，一年后该token过期
 iat: 1671550264,
 nbf: 1671550264,
 iss: "https://kubernetes.default.svc.cluster.local",
 kubernetes.io: {
  namespace: "kube-system",
  pod: {
   name: "xxx",
   uid: "c7300d73-c716-4bbc-ad2b-80353d99073b"
  },
  serviceaccount: {
   name: "multus",
   uid: "1600e098-6a86-4296-8410-2051d45651ce"
  },
  warnafter: 1671553871
 },
 sub: "system:serviceaccount:kube-system:xxx"
}.

查看相关issue[1,2,3]，基本确认是k8s版本迭代引起的，为了提供更安全的token机制，从v1.21版本开始，BoundServiceAccountTokenVolume特性进入beta版本，并默认启用。

解决方案

阅读全文 »

发表于 更新于 分类于 阅读时长 ≈ 7 分钟

编译过程

参考官方资料[1]，执行编译命令：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[root@node01 projectcalico]# make -C node image
"Build dependency versions"
BIRD_VERSION          = v0.3.3-151-g767b5389
"Test dependency versions"
CNI_VER               = master
"Calico git version"
GIT_VERSION           =
make: Entering directory `/home/go/gopath/src/github.com/projectcalico/node'
mkdir -p .go-pkg-cache bin /home/go/gopath/pkg/mod && docker run --rm --net=host --init -e GOPRIVATE='github.com/tigera/*' -e GO111MODULE=on -v /home/go/gopath/pkg/mod:/go/pkg/mod:rw -e LOCAL_USER_ID=0 -e GOCACHE=/go-cache -e GOARCH=amd64 -e GOPATH=/go -e OS=linux -e GOOS=linux -e GOFLAGS= -v /home/go/gopath/src/github.com/projectcalico/node:/go/src/github.com/projectcalico/node:rw -v /home/go/gopath/src/github.com/projectcalico/node/.go-pkg-cache:/go-cache:rw -w /go/src/github.com/projectcalico/node calico/go-build:v0.40 sh -c ' go mod download'
...
Starting with UID : 0
useradd: UID 0 is not unique
su-exec: getpwnam(user): Success
make: *** [remote-deps] Error 1
make: Leaving directory `/home/go/gopath/src/github.com/projectcalico/node'

从日志看，构建在remote-deps阶段失败，错误是useradd: UID 0 is not unique。从日志中的docker启动容器的命令看，是有个LOCAL_USER_ID=0的参数，说明是想以root用户起容器，但这个过程执行了useradd命令添加用户（理论上是不应该执行到这里的）。

分析calico-node的entrypoint.sh，如果是以root用户启动，代码走到第10行就结束了，而判断是否为root用户的依据是RUN_AS_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
#!/bin/bash

# Add local user
# Either use the LOCAL_USER_ID if passed in at runtime or
# fallback

USER_ID=${LOCAL_USER_ID:-9001}

if [ "${RUN_AS_ROOT}" = "true" ]; then
  exec "$@"
fi

echo "Starting with UID : $USER_ID" 1>&2
# Do not create mail box.
/bin/sed -i 's/^CREATE_MAIL_SPOOL=yes/CREATE_MAIL_SPOOL=no/' /etc/default/useradd
# Don't pass "-m" to useradd if the home directory already exists (which can occur if it was volume mounted in) otherwise it will fail.
if [[ ! -d "/home/user" ]]; then
    /usr/sbin/useradd -m -U -s /bin/bash -u $USER_ID user
else
    /usr/sbin/useradd -U -s /bin/bash -u $USER_ID user
fi

...

exec /sbin/su-exec user "$@"

从make的执行结果看，没有发现RUN_AS_ROOT变量，再查看calico-node的Makefile文件，也没有定义，猜测是缺少了RUN_AS_ROOT变量定义导致的：

1
[root@node01 projectcalico]# grep -r "RUN_AS_ROOT" ./node/

参考官网资料[2]，发现go-build的Makefile里有针对root用户的处理：

1
2
3
4
ifeq ("$(LOCAL_USER_ID)", "0")
# The build needs to run as root.
EXTRA_DOCKER_ARGS+=-e RUN_AS_ROOT='true'
endif
阅读全文 »

发表于 更新于 分类于 阅读时长 ≈ 6 分钟

问题背景

客户的防火墙抓到了没有Endpoint的Service请求，从K8S角度来说，正常情况下不应该存在这种现象的，因为没有Endpoint的Service请求会被iptables规则reject掉才对。

分析过程

先本地环境复现，创建一个没有后端的服务，例如grafana-service111：

1
2
3
4
5
6
7
8
9
10
11
 [root@node01 ~]# kubectl get svc -A
NAMESPACE     NAME                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                  AGE
default       kubernetes               ClusterIP   10.96.0.1       <none>        443/TCP                  2d
kube-system   grafana-service          ClusterIP   10.96.78.163    <none>        3000/TCP                 2d
kube-system   grafana-service111       ClusterIP   10.96.52.101    <none>        3000/TCP                 13s

[root@node01 ~]# kubectl get ep -A
NAMESPACE     NAME                      ENDPOINTS                                                       AGE
default       kubernetes                10.10.72.15:6443                                                2d
kube-system   grafana-service           10.78.104.6:3000,10.78.135.5:3000                               2d
kube-system   grafana-service111        <none>                                                          18s

进入一个业务Pod，并请求grafana-service111，结果请求卡住并超时终止：

1
2
3
4
5
6
7
[root@node01 ~]# kubectl exec -it -n kube-system   influxdb-rs1-5bdc67f4cb-lnfgt bash
root@influxdb-rs1-5bdc67f4cb-lnfgt:/# time curl http://10.96.52.101:3000
curl: (7) Failed to connect to 10.96.52.101 port 3000: Connection timed out

real    2m7.307s
user    0m0.006s
sys     0m0.008s

查看grafana-service111的iptables规则，发现有reject规则，但从上面的实测现象看，应该是没有生效：

1
2
[root@node01 ~]# iptables-save |grep 10.96.52.101
-A KUBE-SERVICES -d 10.96.52.101/32 -p tcp -m comment --comment "kube-system/grafana-service111: has no endpoints" -m tcp --dport 3000 -j REJECT --reject-with icmp-port-unreachable

在业务Pod容器网卡上抓包，没有发现响应报文（不符合预期）：

阅读全文 »

发表于 更新于 分类于 阅读时长 ≈ 14 分钟

问题背景

为了验证最新版本的k8s是否已修复某个bug，需要快速搭建一个k8s环境，本文选取资料[1]中的kubeasz工具，并记录部署过程及相关问题。

部署过程

先下载工具脚本、kubeasz代码、二进制、默认容器镜像。

使用如下命令开始安装：

1
2
3
4
5
6
7
8
9
10
11
12
[root@node01 k8s]# ./ezdown -S
2023-03-22 13:39:40 INFO Action begin: start_kubeasz_docker
2023-03-22 13:39:41 INFO try to run kubeasz in a container
2023-03-22 13:39:41 DEBUG get host IP: 10.10.11.49
2023-03-22 13:39:41 DEBUG generate ssh key pair
# 10.10.11.49 SSH-2.0-OpenSSH_6.6.1
f1b442b7fdaf757c7787536b17d12d76208a2dd7884d56fbd1d35817dc2e94ca
2023-03-22 13:39:41 INFO Action successed: start_kubeasz_docker

[root@node01 k8s]# docker ps
CONTAINER ID   IMAGE                                                       COMMAND                  CREATED          STATUS          PORTS     NAMES
f1b442b7fdaf   easzlab/kubeasz:3.5.0                                       "sleep 36000"            15 seconds ago   Up 14 seconds             kubeasz

执行后看不出是成功，还是失败。根据文档说明，进入容器内手动执行命令：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[root@node01 ~]# docker exec -it kubeasz ezctl start-aio
2023-03-22 06:15:05 INFO get local host ipadd: 10.10.11.49
2023-03-22 06:15:05 DEBUG generate custom cluster files in /etc/kubeasz/clusters/default
2023-03-22 06:15:05 DEBUG set versions
2023-03-22 06:15:05 DEBUG disable registry mirrors
2023-03-22 06:15:05 DEBUG cluster default: files successfully created.
2023-03-22 06:15:05 INFO next steps 1: to config '/etc/kubeasz/clusters/default/hosts'
2023-03-22 06:15:05 INFO next steps 2: to config '/etc/kubeasz/clusters/default/config.yml'
ansible-playbook -i clusters/default/hosts -e @clusters/default/config.yml  playbooks/90.setup.yml
2023-03-22 06:15:05 INFO cluster:default setup step:all begins in 5s, press any key to abort:

PLAY [kube_master,kube_node,etcd,ex_lb,chrony] **********************************************************************************************************************************************************

TASK [Gathering Facts] **********************************************************************************************************************************************************************************
fatal: [10.10.11.49]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: root@10.10.11.49: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).", "unreachable": true}

PLAY RECAP **********************************************************************************************************************************************************************************************
10.10.11.49               : ok=0    changed=0    unreachable=1    failed=0    skipped=0    rescued=0    ignored=0

从日志看，提示权限有问题。实际测试可以正常的ssh免密登录：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
bash-5.1# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/root/.ssh/id_rsa already exists.
Overwrite (y/n)?
bash-5.1# ssh-copy-id root@10.10.11.49
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
expr: warning: '^ERROR: ': using '^' as the first character
of a basic regular expression is not portable; it is ignored
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@10.10.11.49's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'root@10.10.11.49'"
and check to make sure that only the key(s) you wanted were added.

bash-5.1# ssh root@10.10.11.49
root@10.10.11.49's password:
阅读全文 »

发表于 更新于 分类于 阅读时长 ≈ 4 分钟

背景

说起开发工具Goland，做Go语言开发的同学应该都不陌生，但由于大部分同学的电脑资源有限，尤其是公司里配备的电脑，在本地使用Goland多多少少有些不够顺畅。

如果公司内服务器资源充足，再加上容器化技术的加持，把Goland以容器的形式部署在服务器上运行是一个不错的解决方法。带着这个想法搜索资料[1]发现，Goland官方还真的开发了容器版，并且提供网页和客户端两种登录方式。下面给出内网环境下的配置步骤及采坑记录：

注：

  1. 以下操作同样适用于Jetbrains旗下的其他开发工具，比如IDEA。
  2. Goland的注册方法不在本次教程讨论范围之内，请自行解决。

镜像获取

Goland网页版功能是jetbrains官方[2]提供的Docker镜像，所以内网配置的前提是先从外网拉取到需要的镜像，然后导出镜像包并拷贝到内网中：

1
2
docker pull registry.jetbrains.team/p/prj/containers/projector-goland
docker save -o projector-goland.tar registry.jetbrains.team/p/prj/containers/projector-goland

注：如果无法拉取官方的镜像，可以在公众号后台回复 docker goland 即可获取goland 网页版镜像。

服务启动

拿到镜像后，找一个安装了docker的服务器或虚机，使用docker run命令启动：

阅读全文 »

发表于 更新于 分类于 阅读时长 ≈ 5 分钟

问题背景

继《Karaf框架升级Lg4j历程》之后，今天又接到通知，需要将版本再升级到2.18.0，据说还是因为漏洞问题。网上查找，未发现有爆出什么漏洞，只找到了一个腾讯发布的相关通知《Apache Log4j官网普通更新》。

分析过程

有了前文的分析，我们知道，要解决漏洞，有三种升级方式：

  1. 升级框架：这个影响就比较大了，而且框架的版本发布周期比较慢，目前还没有编译好的框架包，要升级框架就需要自己编译出所有的框架包，风险较大；
  2. 升级依赖包：影响较小，如果没有配置依赖包的地方，可能无法升级；（实际确认，无法单独升级）
  3. 修改当前版本依赖包并重新编译：影响较小，如果与最新版本跨度较大，可能修改点会很多；

综合比较，继续考虑使用第3个方案走走看，有了前文的经验，就直接修改依赖包版本到2.18.0

1
2
3
4
5
6
7
8
9
pom.xml
        <version.org.apache.felix.configadmin>1.9.20</version.org.apache.felix.configadmin>
        <version.org.apache.felix.framework>5.6.12</version.org.apache.felix.framework>
        <version.org.apache.felix6.framework>6.0.3</version.org.apache.felix6.framework>
-       <version.org.apache.logging.log4j>2.17.0</version.org.apache.logging.log4j>
+       <version.org.apache.logging.log4j>2.18.0</version.org.apache.logging.log4j>
        <version.org.apache.servicemix.bundles.javax-inject>1_3</version.org.apache.servicemix.bundles.javax-inject>
        <version.org.jboss.logging>3.4.1.Final</version.org.jboss.logging>
        <version.org.mockito>3.7.7</version.org.mockito>

编译：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
root@895be557c3cd:/home/org.ops4j.pax.logging-logging-1.11.9# mvn clean install -Dmaven.test.skip=true
...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] OPS4J Pax Logging (Build POM) 1.11.9 ............... SUCCESS [  2.355 s]
[INFO] OPS4J Pax Logging - API (Java9) .................... SUCCESS [  2.039 s]
[INFO] OPS4J Pax Logging - API ............................ SUCCESS [  4.926 s]
[INFO] OPS4J Pax Logging - Log4Jv1 implementation ......... SUCCESS [  2.235 s]
[INFO] OPS4J Pax Logging - Log4Jv2 implementation ......... SUCCESS [  3.051 s]
[INFO] OPS4J Pax Logging - Log4j v2 Extra packages ........ SUCCESS [  0.146 s]
[INFO] OPS4J Pax Logging - Logback implementation ......... SUCCESS [  0.950 s]
[INFO] OPS4J Pax Logging - Integration Tests .............. SUCCESS [  0.354 s]
[INFO] OPS4J Pax Logging - Karaf .......................... SUCCESS [  0.014 s]
[INFO] OPS4J Pax Logging - Karaf KAR Logger ............... SUCCESS [  0.142 s]
[INFO] OPS4J Pax Logging - Karaf KAR ...................... SUCCESS [  1.710 s]
[INFO] OPS4J Pax Logging - Karaf Distribution ............. SUCCESS [  2.522 s]
[INFO] OPS4J Pax Logging - Karaf Integration Tests 1.11.9 . SUCCESS [  0.703 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 22.711 s
[INFO] Finished at: 2022-10-20T03:50:21Z
[INFO] ------------------------------------------------------------------------

把新编译的pax-logging-api和pax-logging-log4j替换到依赖仓库中，重新编译交付件，发现日志功能异常，服务不再打印任何日志了，定位都无从下手；

阅读全文 »

发表于 更新于 分类于 阅读时长 ≈ 3 分钟

漏洞描述

漏洞原理参考资料[1]，简单来说就是，当服务器SSL/TLS的瞬时Diffie-Hellman公共密钥小于等于1024位时，存在可以恢复纯文本信息的风险。

复现方法很简单，使用nmap -sV -Pn --script ssl-dh-params port ip 命令扫描[2]，存在如下漏洞信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
nmap.exe -sV -Pn --script ssl-dh-params 443 192.168.1.10
Starting Nmap 7.92 ( https://nmap.org ) at 2022-07-09 11:14
Nmap scan report for 192.168.1.10
Host is up (0.0033s latency).
Not shown: 996 closed tcp ports (reset)
…
| ssl-dh-params:
|   VULNERABLE:
|   Diffie-Hellman Key Exchange Insufficient Group Strength
|     State: VULNERABLE
|       Transport Layer Security (TLS) services that use Diffie-Hellman groups
|       of insufficient strength, especially those using one of a few commonly
|       shared groups, may be susceptible to passive eavesdropping attacks.
|     Check results:
|       WEAK DH GROUP 1
|             Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
|             Modulus Type: Safe prime
|             Modulus Source: RFC2409/Oakley Group 2
|             Modulus Length: 1024
|             Generator Length: 8
|             Public Key Length: 1024
|     References:
|_      https://weakdh.org

修复方案

参考[3,4]，修改方案如下：

1
2
3
4
[root@node1 etc]# cat org.ops4j.pax.web.cfg
...
# Excluded SSL/TLS Cipher Suites comma-separated list of Regular Expressions
org.ops4j.pax.web.ssl.ciphersuites.excluded=.*NULL.*,.*RC4.*,.*MD5.*,.*DES.*,.*DSS.*,TLS_DHE.*,SSL.*,.*anon.*,.*EXPORT.*

修改后，再次使用nmap -sV -Pn --script ssl-dh-params port ip查看扫描结果，漏洞解决：

1
2
3
4
5
6
7
8
9
10
11
nmap.exe -sV -Pn --script ssl-dh-params 443 192.168.1.10（主机IP）
Starting Nmap 7.92 ( https://nmap.org ) at 2022-07-07 11:53
Nmap scan report for 192.168.1.10
Host is up (0.0032s latency).
Not shown: 997 closed tcp ports (reset
PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 7.4 (protocol 2.0)
111/tcp  open  rpcbind  2-4 (RPC #100000)
...
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 18.74 seconds

需要注意的是，添加完上面的参数后，可能会出现一个新的问题，扫描结果如下：

阅读全文 »

发表于 更新于 分类于 阅读时长 ≈ 4 分钟

本次发现的问题是踩到了新版本Kubernetes的坑，查找资料发现zhangsi-lzq大佬已经分析的很清楚了，此处转载过来仅做学习记录，并新增永久解决方案。

作者：zhangsi-lzq
本文出处：https://www.cnblogs.com/zhangsi-lzq/p/14292628.html

问题背景

Kubernetes升级为1.20版本后，原有的后端nfs存储storageclass无法自动创建PV。查看PVC状态一直为pending状态。

分析过程

查看nfs-provisioner日志：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
kubectl logs nfs-client-provisioner-5f696dc8bb-qhmsn
E0118 03:01:07.352670       1 streamwatcher.go:109] Unable to decode an event from the watch stream: http2: server sent GOAWAY and closed the connection; LastStreamID=3737, ErrCode=NO_ERROR, debug=""
E0118 03:01:07.353951       1 reflector.go:322] github.com/kubernetes-incubator/external-storage/lib/controller/controller.go:668: Failed to watch *v1.StorageClass: Get https://10.96.0.1:443/apis/storage.k8s.io/v1/storageclasses?resourceVersion=604432&timeoutSeconds=387&watch=true: dial tcp 10.96.0.1:443: connect: connection refused
W0118 03:01:07.366606       1 reflector.go:341] github.com/kubernetes-incubator/external-storage/lib/controller/controller.go:665: watch of *v1.PersistentVolume ended with: too old resource version: 11565 (605173)
W0118 03:01:07.367679       1 reflector.go:341] github.com/kubernetes-incubator/external-storage/lib/controller/controller.go:662: watch of *v1.PersistentVolumeClaim ended with: too old resource version: 11565 (605173)
I0118 03:08:28.340240       1 controller.go:987] provision "default/auth-platorm-redis-data-auth-platorm-redis-cluster-0" class "course-nfs-storage": started
E0118 03:08:28.343582       1 controller.go:1004] provision "default/auth-platorm-redis-data-auth-platorm-redis-cluster-0" class "course-nfs-storage": unexpected error getting claim reference: selfLink was empty, can't make reference
I0118 03:16:08.373590       1 controller.go:987] provision "default/auth-platorm-redis-data-auth-platorm-redis-cluster-0" class "course-nfs-storage": started
E0118 03:16:08.382178       1 controller.go:1004] provision "default/auth-platorm-redis-data-auth-platorm-redis-cluster-0" class "course-nfs-storage": unexpected error getting claim reference: selfLink was empty, can't make reference
I0118 03:30:41.647626       1 controller.go:987] provision "default/test-pvc" class "course-nfs-storage": started
E0118 03:30:41.658419       1 controller.go:1004] provision "default/test-pvc" class "course-nfs-storage": unexpected error getting claim reference: selfLink was empty, can't make reference
I0118 03:31:08.373713       1 controller.go:987] provision "default/auth-platorm-redis-data-auth-platorm-redis-cluster-0" class "course-nfs-storage": started
I0118 03:31:08.373969       1 controller.go:987] provision "default/test-pvc" class "course-nfs-storage": started
E0118 03:31:08.382279       1 controller.go:1004] provision "default/test-pvc" class "course-nfs-storage": unexpected error getting claim reference: selfLink was empty, can't make reference
E0118 03:31:08.382791       1 controller.go:1004] provision "default/auth-platorm-redis-data-auth-platorm-redis-cluster-0" class "course-nfs-storage": unexpected error getting claim reference: selfLink was empty, can't make reference

报错信息selfLink was empty，于是上网查询相关内容，在官方1.20的变更说明中[1]看到其中一条说明为：

1
Stop propagating SelfLink (deprecated in 1.16) in kube-apiserver

selfLink在1.16版本以后已经弃用，在1.20版本停用。而由于nfs-provisioner的实现是基于selfLink功能（同时也会影响其他用到selfLink这个功能的第三方软件），需要等nfs-provisioner的制作方重新提供新的解决方案。

阅读全文 »

发表于 更新于 分类于 阅读时长 ≈ 3 分钟

问题背景

  1. 查看kube-system下的系统组件，发现harbor、influxdb、coredns等组件反复重启；
  2. 使用kubectl get pod -n kube-system命令查看pod列表，发现命令会稳定的卡15s；

原因分析

先看第一点，这几个pod反复重启已经遇到过几次，看过前面的问题排查文章[1,2]的应该知道，在业务高并发场景下可能出现。先使用top命令看一下负载情况：

1
2
3
4
5
6
load average: 14.76  18.45  17.85
Tasks: 1998 total,  7 running,  1937 sleeping, 0 stopped,  54 zombie
%CPU: 15.2 us, 8.3 sys, 0.7 ni, 75.3 id

cat /proc/cpuinfo|grep MHz| wc -l
40

实际负载不高，排除这个可能（实际定位过程中，也依据前面的经验，做了相关内核参数的优化，问题确实没什么改善）。那就继续看，先describe看几个异常pod的错误信息：

1
2
3
kubelet     Liveness probe failed: Get "http://177.177.138.139:8885/api/health": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
kubelet     Readiness probe failed: Get "http://177.177.138.139:8083/"": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
kubelet     Back-off restarting failed container

错误基本一致，就是kubelet调用pod提供的健康检查接口超时了，所以被不断地kill再重启。为什么调不通？模拟kubelet的调用操作，在pod所在节点上使用curl命令调用，结果显示timeout，再ping一下看看pod通信有没有问题：

1
2
ping 177.177.212.186
^C

ping不通！这也就讲通了为啥健康检查不过，因为kubelet与所在节点上的Pod根本就无法通信。为啥会这样？通过一顿验证，发现一个规律：集群各节点无法访问自己节点上的pod，但可以访问其他节点上的pod；

阅读全文 »