k8s-01-组件容器时区修改

已于 2022-03-11 17:48:14 修改
阅读量1.6k 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： kubernetes 实战 文章标签： 容器 kubernetes docker
于 2022-01-05 14:50:54 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/sunnyliuqi/article/details/122323557
本文详细介绍了如何在Kubernetes环境中修改各关键组件（etcd、kube-controller-manager、kube-scheduler、kube-apiserver、kube-proxy和coredns）的时区设置，确保整个集群的时间同步和正确运行。

# 挂在主机时区文件模版

...
      volumeMounts:
        - mountPath: /etc/localtime
          name: host-time
          readOnly: true
...
    volumes:
      - hostPath:
          path: /etc/localtime
          type: ""
        name: host-time


# 修改etcd

vi /etc/kubernetes/manifests/etcd.yaml
...
    - mountPath: /etc/localtime
      name: host-time
      readOnly: true
...
  - hostPath:
      path: /etc/localtime
      type: ""
    name: host-time


# 修改kube-control

了解本专栏 订阅专栏 解锁全文 超级会员免费看
Kubernetes 3种时区设置方式
oopxiajun博客专栏
01-26 1万+
一：设置PodPreset 1. PodPreset 的作用 将一些公用的参数设置到pod中去，例如 时区统一设置为东八区等 2. API Server 开启PodPreset 编辑文件 /etc/kubernetes/manifests/kube-apiserver.yaml， 添加 --runtime-config=settings.k8s.io/v1alpha1=true， 添加 --admission-control=PodPreset(新版本是--enable-admission-pl
k8s-1.26.6 二进制部署
小五
08-03 1368
公有云要用公有云自带的负载均衡，比如阿里云的SLB，腾讯云的ELB，用来替代haproxy和keepalived，因为公有云大部分都是不支持keepalived的，另外如果用阿里云的话，kubectl控制端不能放在master节点，推荐使用腾讯云，因为阿里云的slb有回环的问题，也就是slb代理的服务器不能反向访问SLB，但是腾讯云修复了这个问题。下载地址：https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md。
k8s通过应用修改yaml文件修改容器时区
tingting0119的博客
07-26 651
通过挂载把本地的/etc/localtime挂载到容器中是容器的时间与服务器已知
K8S基础服务（apiserver、controller、scheduler、etcd）时区设置
那个那个
11-08 1422
K8S基础服务（apiserver、controller、scheduler、etcd）时区设置。
解决k8s容器时区(差8小时)不一致问题
qq_43164571的博客
05-17 5080
部署项目以后日志打印和当前咱们所在的时间差8个小时，应该是国外的标准时区，只能改成咱们自己的时区，我的解决方式是这样的 默认k8s是没有开启PodPreset的，需要开启,命令如下 vim /etc/kubernetes/manifests/kube-apiserver.yaml 在末尾添加以下内容 - --runtime-config=settings.k8s.io/v1alpha1=true 再在enable-admission-plugins=NodeRestriction下加一个PodPres
K8S 为全局pod设置时区
u010389826的博客
08-18 1689
使用PodPreset可以修改所有容器的时区（在pod 创建时,用户可以使用 podpreset 对象将特定信息注入 pod 中,这些信息可以包括 secret、 卷、 卷挂载和环境变量）
Centons7.8通过kubeadm快速部署k8s-v1.22.0
ferdfd的博客
08-27 1513
Centons7.8通过kubeadm快速部署k8s-v1.22.0（全网最详细且无坑）
精选资源
二进制部署k8s高可用集群（二进制-V1.20）.docx
06-29
二进制方式是使用二进制文件来部署 K8s 集群，而容器方式是使用容器来部署 K8s 集群。二进制方式相对简单，但需要手动配置每个组件，而容器方式可以自动化配置，但需要较高的资源占用。 2. 准备环境 在部署 K8s ...
k8s-集群安装
hxy1625309592的博客
07-04 1121
1-Kubernetes 是什么？ 1.1常见的云平台 IaaS(Infrastructure as a Service)：基础设施服务，常见平台阿里云。 PaaS(platform as a service)：平台即服务，常见平台如新浪云。 SaaS（Software as a Service）：软件即服务，常见平台Office365。 Kubernetes(PaaS)是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长
K8S里的docker时区设置
welcome66的专栏
05-13 2434
最近发现有些镜像里，时区设置的是标准时区UTC，不是CST，需要修改docker的时区，设置成东八区。 修改docker的时区，有几个方法，如修改镜像、docker启动修改参数、docker上配置时区目录文件、docker直接修改时区等。 下面分别说明： 1.修改Dockerfile RUN rm -f /etc/localtime \ && ln -sv /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \ && e
K8S pod 时区设置
07-14 6386
K8S 中默认使用0时区，如果不设置为当前时区，有些应用会报错，比如 minio 等；查看原时区： nsName 是命名空间； 此时时区是 UTC；打开之前的 dp.yaml 文件，在其中添加上 /etc/localtime 文件的挂载 此步，也可以在 dashboard 中直接编辑 yaml 配置，但最好是每次调整都编辑原始文件，这样省的某次的修改以后找不到了；重新发布： 重启后，再到 pod 中查看当前时间 时区和时间都正常了！...
关于k8s内 容器时间为UTC,差8小时的解决的方式（linux-centos7）
weixin_45969972的博客
06-14 4179
k8s修改容器UTC时区问题
Docker/K8s 解决容器内时区不一致方案
热门推荐
哎_小羊的博客
03-08 2万+
使用 docker 容器启动服务后，如果使用默认 Centos 系统作为基础镜像，就会出现系统时区不一致的问题，因为默认 Centos 系统时间为 UTC 协调世界时 (Universal Time Coordinated)，一般本地所属时区为 CST（＋8 时区，上海时间），时间上刚好相差 8 个小时。这就导致了，我们服务启动后，获取系统时间来进行相关操作，例如存入数据库、时间换算、日志记录等，都会出现时间不一致的问题，所以很有必要解决掉容器内时区不统一的问题。
Kubernetes实战(二十二)-Pod时区修改
sre救赎之路
02-01 1493
一般国内引用的基础镜像时区都是 UTC 时区，在此基础上，如果去容器查看日志的话就会发现和本地时间对不上，会导致一些问题出现，比如输出的日志时间和当前不一致，所以一般都会把操作系统或容器里的时区替换为 Shanghai。
k8s-pod挂载服务器本地时间、字体
惰立的博客
05-05 732
k8s-pod挂载服务器本地时间、字体
k8s集群统一设置时间
liu289747235的专栏
05-06 2142
k8tz 可以使用hostPath的方式，或者将emptyDir 注入initContainer并用 TZif（时区信息格式) 文件填充卷。然后将emptyDir挂载到 Pod 每个容器的 /etc/localtime和 /usr/share/zoneinfo。将k8tz挂载目录子目录的subpath挂载至/etc/localtime目录下。初始化容器将/mnt/zoneinfo挂载定义k8tz，为（3）做准备。将k8tz整个目录挂载到/usr/share/zoneinfo目录下。
k8s集群修改pod中容器的时间
qq_42502583的博客
04-01 7218
k8s集群 修改pod中容器的时间 问题 当需要测试某些功能时，需要修改系统时间，当进入pod的容器之后，执行date命令报错！！！ root@world-106-5bb9785bd8-7rlmd:/app# date -s 23:50:00 date: cannot set date: Operation not permitted Thu 01 Apr 2021 11:50:00 PM CST 原因 k8s集群底层的容器技术是基于docker(大部分)来实现的，而docker的安全隔离是基于Linux
容器内修改时间方案
qq_38085379的博客
07-21 735
在容器中修改自定义时间，不影响宿主机和其他容器
k8s podPreset更改所有容器时间为当地时间。
lyf0327的博客
05-10 4021
问题：docker 容器默认会采用utc时区，所以K8s所起容器会比当前时间慢八个小时。 解决：通过Pod Preset预设置时区环境变量或挂载宿主机时间 1.配置设置时区的Pod Preset 对应的Pod Preset对象创建文件如下： apiVersion: settings.k8s.io/v1alpha1 kind: PodPreset metadata: name: allow-tz...
是否因为我的原本集群存在问题 huitian@k8s-control-1:~$ kubectl get pods -n kube-system NAME READY STATUS RESTARTS AGE coredns-55cb58b774-8c9zq 1/1 Running 0 15h coredns-55cb58b774-bwpm6 1/1 Running 0 15h etcd-k8s-control-1 1/1 Running 0 15h etcd-k8s-control-2 0/1 ContainerCreating 0 49m kube-apiserver-k8s-control-1 1/1 Running 0 15h kube-apiserver-k8s-control-2 0/1 ContainerCreating 0 71m kube-controller-manager-k8s-control-1 0/1 CreateContainerError 0 15h kube-controller-manager-k8s-control-2 0/1 ContainerCreating 0 71m kube-proxy-vlkb8 0/1 ContainerCreating 5 (69m ago) 71m kube-proxy-w258w 1/1 Running 0 15h kube-scheduler-k8s-control-1 0/1 CreateContainerError 0 15h kube-scheduler-k8s-control-2 0/1 ContainerCreating 0 71m
最新发布
08-14
<think>我们当前的任务是检查Kubernetes集群状态及排查节点加入失败的原因。根据用户提供的日志，节点在加入过程中在etcd步骤失败，错误信息为"etcdserver: can only promote a learner member which is in sync with leader"。 这个错误通常表示新加入的etcd成员（learner）还没有完成与leader的数据同步，因此不能被提升为投票成员。我们需要检查etcd集群的状态，确保新节点能够与现有etcd集群正常通信，并且数据同步能够完成。 以下是解决步骤： 1. **检查现有etcd集群状态**：在已经正常运行的control plane节点上执行命令，查看etcd成员的状态。 2. **检查新节点的etcd日志**：在新节点上，查看etcd容器的日志，确认同步过程是否在进行，是否有错误。 3. **检查网络连接**：确保新节点与现有etcd集群节点之间的网络连通性，特别是2379（etcd客户端）和2380（etcd peer）端口。 4. **检查时间同步**：确保所有节点的时间同步，时间不同步可能导致etcd出现问题。 5. **手动干预**：如果同步一直无法完成，可以考虑将新节点从etcd集群中移除，然后重新加入。 由于用户没有提供集群的kubeconfig，我们假设可以在控制节点上执行命令。 具体操作： 步骤1：检查etcd集群成员状态 在已有的控制节点上执行： ```bash kubectl exec -it -n kube-system etcd-<existing-control-plane-node> -- etcdctl --write-out=table --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key member list ``` 注意：将`<existing-control-plane-node>`替换为已有的etcd pod所在的节点名称。 步骤2：检查新节点的etcd日志 在新节点上，由于etcd是以静态pod运行的，我们可以通过以下命令查看日志： ```bash journalctl -u kubelet -f | grep etcd ``` 或者直接查看etcd容器的日志（如果使用docker）： ```bash docker logs $(docker ps | grep etcd | awk '{print $1}') ``` 步骤3：检查网络连通性 在新节点上，使用telnet或nc检查与现有etcd节点端口的连通性： ```bash nc -zv <existing-etcd-node-ip> 2379 nc -zv <existing-etcd-node-ip> 2380 ``` 步骤4：检查时间同步 在所有节点上运行： ```bash timedatectl ``` 确保时区和时间一致。 步骤5：如果发现新节点在etcd成员列表中处于learner状态且长时间未同步，可以尝试将其移除然后重新加入。但注意，移除操作需要谨慎，因为可能会影响集群。 移除成员（在etcd集群中的一个正常节点上执行）： 首先，获取新节点的etcd成员ID（通过步骤1中的命令获取）。 然后，移除该成员： ```bash etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key member remove <member-id> ``` 然后，在新节点上清理etcd数据目录（通常为/var/lib/etcd），并重新运行kubeadm join命令。 但是，请注意，重新运行kubeadm join之前，需要确保之前加入过程中生成的文件被清除。可以执行： ```bash kubeadm reset ``` 然后再次尝试加入。 另外，用户提供的日志中，使用了`--cri-socket=unix:///var/run/cri-dockerd.sock`，说明使用的是docker作为容器运行时。需要确保docker服务正常运行。 根据引用[2]中的情况，coredns处于CrashLoopBackOff状态，可能也是因为etcd集群不正常导致。因此，解决etcd问题后，coredns可能会恢复正常。 总结：当前主要问题是etcd新成员同步失败，需要按照上述步骤进行排查。 由于用户的问题描述中，在加入控制平面节点时出现了etcd同步问题，我们将重点放在etcd集群的排查上。 现在，我们生成相关的操作步骤和命令，供用户执行以排查问题。</think>### Kubernetes 集群状态检查与节点加入失败排查指南 #### 1. 检查集群核心组件状态 ```bash # 在正常控制节点执行 kubectl get pods -n kube-system -o wide ``` **关键检查点**： - `etcd` Pod 状态：应全部为 `Running`（如引用[2]所示） - `kube-apiserver` 是否正常运行 - `coredns` 状态：避免 `CrashLoopBackOff`（如引用[2]中的问题） - 节点分布：确保组件均匀分布在多个控制平面节点 #### 2. 诊断 etcd 集群健康 ```bash # 在正常控制节点执行 ETCDCTL_API=3 etcdctl \ --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ endpoint health --cluster ``` **预期输出**： ```plaintext https://10.32.11.221:2379 is healthy: successfully committed proposal... https://10.32.11.222:2379 is healthy: successfully committed proposal... ``` #### 3. 检查节点加入失败原因 根据您的日志，核心问题是： ```plaintext etcdserver: can only promote a learner member which is in sync with leader ``` **解决步骤**： 1. **检查新节点时间同步**： ```bash timedatectl status chronyc tracking # 确保所有节点时间偏差 < 1s ``` 2. **验证证书有效性**（如引用[1]要求）： ```bash # 新节点上检查 kubelet 客户端证书 openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text -noout | grep -E "Issuer:|Extended Key Usage" ``` 3. **检查网络连通性**： ```bash # 在新节点执行 telnet 10.32.11.221 6443 # API Server 端口 nc -zv 10.32.11.221 2379 # etcd 客户端端口 ``` 4. **查看详细日志**： ```bash journalctl -u kubelet -f | grep -i etcd docker logs $(docker ps | grep etcd | awk '{print $1}') # 容器运行时日志 ``` #### 4. 强制重置并重试加入 ```bash # 在故障节点执行 sudo kubeadm reset -f sudo rm -rf /etc/kubernetes/pki sudo systemctl restart docker cri-dockerd kubelet # 重新加入（增加详细日志） sudo kubeadm join 10.32.11.221:6444 \ --v=5 \ --control-plane \ --token n4xnoa.efsdi56ftehzm3ip \ --discovery-token-ca-cert-hash sha256:eff4c9ab391f809edb6a5733e3b9a1e242202366a8320bba1d89303d7ccc2e38 \ --certificate-key 14002b9dfb4729ac68ed37fa84d0562de57db462b5beba7de813cb451f40227b \ --cri-socket=unix:///var/run/cri-dockerd.sock ``` #### 5. 验证修复效果 ```bash # 成功加入后检查 kubectl get nodes kubectl describe node k8s-control-2 | grep -i ready etcdctl endpoint status --cluster -w table ``` > **关键点**：etcd 数据同步速度取决于集群数据量，1GB 数据量可能需要 10-15 分钟。期间避免中断操作[^3]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

多懂一些

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值