Rancher 自带监控收集非自定义集群 ETCD 监控数据

本文永久链接: https://www.xtplayer.cn/rancher/monitors/rancher-monitors-collection-external-etcd-data/目前,rancher 自带监控暂时只支持收集 rancher 自定义...
继续阅读 »

本文永久链接: https://www.xtplayer.cn/rancher/monitors/rancher-monitors-collection-external-etcd-data/

目前,rancher 自带监控暂时只支持收集 rancher 自定义集群的 ETCD 监控数据。对于 rke 导入集群或者其他导入类型的集群,因为架构的差异,暂时不能直接支持监控 ETCD 监控数据。

rancher 内置监控也是通过 prometheus-operator 部署,只需要自定义一些 serviceMonitor 配置即可实现其他类型集群 ETCD 监控数据收集。

方案介绍

serviceMonitor 是通过对 service 获取数据的一种方式。prometheus-operator 可以通过 serviceMonitor 自动识别带有某些 label 的 service,并从这些 service 获取数据。serviceMonitor 也是由 prometheus-operator 自动发现。

对应一些启用 ssl 认证的服务,需要提供 ssl 证书给 prometheus 用以进行认证 。首先创建一个 secret 用来存放 ssl 证书,再把证书挂载到 prometheus 容器内。接下来创建 ServiceMonitor 对象,用于 Prometheus 添加监控项,再为 ServiceMonitor 对象关联 metrics 数据接口对应的 Service 对象,确保通过 Service 对象可以正确获取到 metrics 数据。

创建 Secrets 挂载证书

在 ETCD 节点中,通过以下命令去创建 ETCD 证书密文:

BASH
kubectl create secret generic etcd-certs -n cattle-prometheus \
--from-file=kube-ca.pem=< kube-ca 文件路径 > \
--from-file=kube-etcd-key.pem=< etcd key 文件路径 > \
--from-file=kube-etcd.pem=< etcd 证书文件路径 >

添加 Secrets 到 Prometheus 容器

依次进入 集群|工具|监控 ,在监控配置页面点击右下角的 显示高级选项。添加 添加应答,添加以下应答:

BASH
prometheus.secrets[0]=etcd-certs
# 如果有多个密文,则依次叠加
prometheus.secrets[1]=xxxx

创建 etcd-server svc,把外部 etcd 服务引入 k8s 集群

  1. 访问 system 项目|服务发现,统计 添加 DNS 记录

    image-20201130184840193.png
  2. 选择 外部 IP 地址,并在右侧的 目标 IP 地址 填写 etcd 节点 ip,命名空间选择 cattle-prometheus

    image-20210223123451393.png
  3. 点击右侧 显示高级选项

    1. 类型选择 headless service

    2. 添加端口映射

      image-20210223123606233.png
  4. 在底部 标签与注释 中添加,最后点击创建。

    BASH
    jobLabel=k8s-etcd-server
    app=k8s-etcd-server
    image-20201130185543247.png

创建 etcd ServiceMonitor 对象

保存以下内容为:prometheus-serviceMonitorEtcd.yaml,然后执行 kubectl apply -f prometheus-serviceMonitorEtcd.yaml

YAML
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: exporter-etcd-server-monitoring
namespace: cattle-prometheus
labels:
app: exporter-etcd-server
spec:
jobLabel: k8s-etcd-server # etcd-server svc 的标签 jobLabel=xxx
endpoints:
- port: https-2379 # 此处的设置需要与 etcd-server svc 中端口映射的 name 对应
scheme: https
interval: 30s
tlsConfig: # 此处的证书路径与密文挂载到 prometheus 容器中的路径一致
caFile: /etc/prometheus/secrets/etcd-certs/kube-ca.pem
certFile: /etc/prometheus/secrets/etcd-certs/kube-etcd.pem
keyFile: /etc/prometheus/secrets/etcd-certs/kube-etcd-key.pem
insecureSkipVerify: true
namespaceSelector:
matchNames:
- cattle-prometheus # etcd-server svc 所在的命名空间
selector:
matchLabels:
app: k8s-etcd-server # etcd-server svc 的标签

验证 prometheus 状态

  1. 点击 system 项目|应用商店 的访问入口,进入 prometheus 管理界面

    image-20201130190651558.png
  2. 点击 Status|Targets 和 Status|Service Discovery 查看状态

    image-20201130190804103.pngimage-20201130191002037.pngimage-20201130191033691.png

验证 Grafana 状态

  • 与 prometheus 相同, 点击 system 项目|应用商店 的访问入口,进入 Grafana 管理界面,点击左上角的 Home

  • 接着点击 ETCD。

  • 如果结果如下图显示,则说明数据可以正常显示,配置成功。

image-20201130191245446.png

收起阅读 »

Kubernetes 概念及其重要性

本文永久链接: https://www.xtplayer.cn/kubernetes/concepts-and-matters/要完全理解该技术,您需要知道为什么使用容器编排工具以及 Kubernetes 是如何出现的。Kubernetes 的故事始于容器,为...
继续阅读 »

本文永久链接: https://www.xtplayer.cn/kubernetes/concepts-and-matters/

要完全理解该技术,您需要知道为什么使用容器编排工具以及 Kubernetes 是如何出现的。Kubernetes 的故事始于容器,为了解容器的好处,让我们看看软件部署机制是如何随着时间演变的。

Docker 容器改变了部署软件的方式

在过去,软件部署相对困难,耗时且容易出错。要安装应用程序,需要购买许多物理机并为 CPU 和内存支付超出实际需要的费用。几年后,虚拟化成为主流。一台功能强大的裸机服务器可以托管多台虚拟机,CPU 和内存可以共享,因此您节省了一些成本。如今,机器可以比虚拟服务器分割成更小的部分 — 容器。容器仅在几年之间变得如此流行。那么,Linux 容器到底是什么?Docker 适合用在什么场景?

machines-1.png

容器就像虚拟机一样提供一种虚拟化的实现,主机管理程序提供了硬件级别的隔离,而容器提供了进程级别的隔离。

为了理解这种差异,让我们回到示例中。

您决定使用容器,而不是为 Apache 和 MySQL 创建虚拟机。现在,您的堆栈如下图所示。

containers-1.png

容器也是操作系统上的一组进程,容器通过 Linux 内核功能(例如:cgroupschrootUnionFS 和 命名空间)与其他进程/容器完全隔离。

这意味着您只需支付一台物理主机的费用,安装一个操作系统,尽可能多的运行容器从而提高资源利用率。减少在同一物理主机上运行所需的操作系统数量,意味着更少的存储,内存和 CPU 浪费。

2010 年,Docker 成立。Docker 可以指公司和产品。Docker 让用户和公司非常容易地利用容器进行软件部署。需要注意的一点是,Docker 并不是市场上唯一能够做到这一点的工具。还有其他应用程序,如 rkt、Apache Mesos、LXC 等,但 Docker 是最受欢迎的一个。

容器和微服务:需要协调器

在同一个操作系统上以进程(也就是容器)的形式运行完整服务的能力是革命性的。它本身带来了很多可能性:

  • 由于容器比虚拟机便宜得多,速度也快得多,所以大型应用程序现在可以被分解成小的、相互依赖的组件,每个组件都在自己的容器中运行。这种体系结构被称为微服务。
  • 随着微服务体系结构越来越占主导地位,应用程序有了更大更丰富的自由。以前,单个应用程序一直在发展,直到达到一定的限制,使其变得笨拙、更难调试,并且非常难以重新部署。然而,随着容器的出现,要向应用程序添加更多特性,所需要做的就是构建更多的容器/服务。使用 IaC(基础设施即代码),部署就像对配置文件运行命令一样简单。
  • 如今,服务不可访问已是不再可接受的。用户根本不在乎您的应用程序是否正在发生网络中断或群集节点崩溃。如果您的系统未运行,则用户将直接切换到您的竞争对手。
  • 容器是过程,而过程本质上是短暂的。如果容器损坏了怎么办?
  • 为了实现高可用性,您为每个组件创建多个容器。例如,Apache 的两个容器,每个容器都托管一个 Web 服务器。但是,其中哪一个将响应客户的请求?
  • 当您需要更新应用程序时,您想利用每个服务的多个容器。您将在容器的一部分上部署新代码,重新创建它们,然后在其余容器上执行相同的操作。但是,手动执行此操作非常困难。更不用说容易出错。
  • 容器配置。
  • 维护正在运行的容器的状态(和数量)。
  • 通过将容器从一个节点移动到另一个节点,将应用程序负载平均分配到硬件节点上。
  • 承载相同服务的容器之间的负载平衡。
  • 处理容器持久性存储
  • 确保即使推出更新,该应用程序始终可用。

以上所有内容都鼓励 IT 专业人员做一件事:创建尽可能多的容器。但是,这也有缺点:

例如,假设您有一个微服务应用程序,该应用程序具有运行 Apache,Ruby,Python 和 NodeJS 的多个服务。您使用容器来充分利用手头的硬件。但是,由于有很多容器分散在您的节点上而没有被管理,因此基础架构可能如下图所示。

inside-containers-1.png

因此,您需要一个容器编排引擎!

欢迎 Kubernetes

Kubernetes 是一个容器编排工具。编排是容器生命周期管理的另一个名称,容器编排引擎执行许多任务。

就像 Docker 并不是目前唯一的容器平台一样,Kubernetes 并不是市场上唯一的编排工具。还有其他工具,例如 Docker SwarmApache MesosMarathon 等。那么,什么使 Kubernetes 成为最常用的呢?

Kubernetes 为什么如此受欢迎?

Kubernetes 最初是由软件和搜索巨头 Google 开发的,Kubernetes 是他们 Borg 项目的一个分支。自成立以来,Kubernetes 受到了开源社区的巨大推动,它是 Cloud Native Computing Foundation 的主要项目。一些最大的市场参与者正在支持它:GoogleAWSAzureIBM 和 Cisco 等。

Kubernetes 体系结构及其环境?

Kubernetes 是一个希腊单词,代表舵手或船长。它是你们集群的管理者,为了能够完成这项关键的工作,Kubernetes 以高度模块化的方式设计。该技术的每个部分都为依赖它的服务提供了必要的基础。下图展示了应用程序如何工作的概览,每个模块都包含在一个更大的模块中,该模块依赖于它的功能。让我们更深入地研究每一个问题。

ecosystem.png

Kubernetes 核心功能

也被称为控制平面,它是整个系统最核心的部分。它提供了许多 RESTful API,使集群能够执行其最基本的操作。核心的另一部分是执行,执行涉及许多控制器,如副本控制器、复制集、部署等。它还包括 kubelet,它是负责与容器运行时通信的模块。

核心还负责联系其他层(通过 kubelet)来全面管理容器。让我们简要地了解它们:

容器运行时

Kubernetes 使用容器运行时接口(CRI)来透明地管理容器,而不必知道(或处理)所使用的运行时。当我们讨论容器时,我们提到了 Docker,尽管它很受欢迎,但并不是唯一可用的容器管理系统。Kubernetes 默认使用 containerd 作为容器运行时。这就是你能够对 Kubernetes 容器发出标准 Docker 命令的方式。它还使用 rkt 作为替代运行时。在这一点上不要太困惑。这是 Kubernetes 的内部工作原理,尽管您需要理解它,但您几乎不必完全处理它。Kubernetes 通过其丰富的 api 对这一层进行了抽象。

网络插件

正如我们前面所讨论的,容器编制系统负责管理容器和服务通信所通过的网络。Kubernetes 使用称为容器网络接口(CNI)的库作为集群和各种网络提供商之间的接口。Kubernetes 中可以使用许多网络供应商。这个数字是不断变化的。举几个例子:

这个清单太长了,在这里就不再一一列举。你可能会问: 为什么 Kubernetes 需要多个网络提供商来进行选择?Kubernetes 的设计主要用于部署在不同的环境中,Kubernetes 节点可以是裸金属物理服务器、虚拟机或云实例中的任何节点。有了这样的多样性,对于容器如何彼此通信,您实际上有无穷多的选择。这需要不止一个人来选择,这就是 Kubernetes 设计者选择将 CNI 背后的网络提供者层抽象出来的原因。

Volume 插件

卷广义上是指将用于 Pod 的存储空间。 Pod 是由 Kubernetes 作为一个单元管理的一个或多个容器。因为 Kubernetes 被设计为部署在多个环境中,所以集群和底层存储之间存在一个抽象层。Kubernetes 还使用 CSI(容器存储接口)来与各种已经可用的存储插件进行交互。

镜像仓库

Kubernetes 必须能够访问镜像仓库(无论是公共的还是私有的)才能获取镜像并创建出容器。

云提供商

Kubernetes 可以部署在您可能想到的几乎任何平台上。但是,大多数用户喜欢使用 AWS,Azure 或 GCP 之类的云提供商,以节省更多成本。Kubernetes 依靠云提供商的 API 来执行可伸缩性和资源供应任务,例如:供应负载平衡器,访问云存储,利用节点间 VPC 网络等。

身份提供者

如果您要在用户数量较少的小型公司中配置 Kubernetes 集群,则身份验证不会成为大问题。您可以为每个用户创建一个帐户。但是,如果您在大型企业中工作,有成百上千的开发人员、操作员、测试人员、安全专业人员等,手动为每个人创建一个帐户可能会变成一场噩梦。Kubernetes 的设计人员在开发身份验证机制时就考虑到了这一点,只要集群使用OpenID connect,您就可以使用自己的身份提供程序系统对集群中的用户进行身份验证。

控制器层

这也称为服务结构层。它负责集群的一些更高级别的功能:路由、自我修复、负载平衡、服务发现和基本部署(有关更多信息,请参考 https://kubernetes.io/docs/concepts/services-networking/ 和 https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)。

管理层

这就是应用策略执行选项的地方。在这一层中,执行指标收集和自动缩放等功能。它还控制授权和不同资源(如网络和存储)之间的配额。您可以访问此处了解更多关于资源配额的信息。

接口层

在这一层中,有用于与集群交互的面向客户端的工具,目前,kubectl 是最受欢迎的客户端程序。在后台,它向 Kubernetes 发出 RESTful API 请求,并根据提供的选项以 JSON 或 YAML 的形式显示响应。kubectl 可以很容易地与其他高级工具集成,以促进集群管理。

在同一领域还有 helm,它可以被认为是运行在 Kubernetes 之上的应用程序包管理器。使用 helm-charts,只需在配置文件中定义其属性/参数,就可以在 Kubernetes 上运行完整的应用服务。

DevOps 和基础架构环境

Kubernetes 是最繁忙的开源项目之一。它有一个庞大的、充满活力的用户社区,它不断地变化以适应新的要求和挑战。Kubernetes 提供了大量的特性。尽管它只有几年的历史,但它能够支持几乎所有类型的环境。Kubernetes 在许多现代软件构建/部署实践中被使用,包括:

  • DevOps: 为测试和 QA 更容易、更快的提供临时环境;
  • CI/CD使用 Kubernetes 管理的容器,构建持续的集成/部署,甚至交付管道也更加无缝连接。您可以轻松地将诸如JenkinsTravisCIDrone CI 之类的工具与 Kubernetes 集成在一起,以构建/测试/部署应用程序和其他云组件。
  • ChatOps像 Slack 这样的聊天应用程序可以轻松地与 Kubernetes 提供的丰富 API 集集成,以监控甚至管理集群。
  • 云托管的 Kubernetes:大多数云提供商都提供已安装 Kubernetes 的产品。例如,AWS EKSGoogle GKE 和 Azure AKS
  • GitOps:Kubernetes 中的所有内容都通过 YAML 文件进行管理。使用 Git 之类的版本控制系统,您可以轻松管理集群应用,甚至不必使用 kubectl
收起阅读 »

了解 Kubernetes 1.20

本文永久链接: https://www.xtplayer.cn/kubernetes/about-kubernetes-1.20/Kubernetes 1.20 版本有 43 个增强(从 1.19 版本增加的 34 个),包括 15 个全新的,11 个升级到稳...
继续阅读 »

本文永久链接: https://www.xtplayer.cn/kubernetes/about-kubernetes-1.20/

Kubernetes 1.20 版本有 43 个增强(从 1.19 版本增加的 34 个),包括 15 个全新的,11 个升级到稳定的,以及 17 个对现有特性的改进。

这表明这些增强的作用范围较小。例如,对 kube-apiserver 进行了一些更改,以使其在 HA 集群中更加友好并具有更好的性能。它还可以在升级后更有效地重新启动。

为什么会这样?

这些小的改进和新特性为未来的重大变化铺平了道路。然而,最新版本已经有了一个主要的变化(尽管人们期待已久)。

Kubernetes 弃用 Docker

从 1.20 版本开始,Kubernetes 将不再支持 Docker 作为容器运行时,而是支持容器运行时接口Container Runtime Interface(CRI)

但是不要惊慌!

这并不意味着 Docker 已经死了,你不必放弃 Docker 工具。对于 Kubernetes 用户来说,不会有太大的改变,因为你仍然可以使用 Docker 构建容器,生成的映像也将继续在 Kubernetes 集群中运行。

然而,Kubernetes 计划在未来的版本中移除 kubelet 和 dockershim 中的 Docker 引擎支持,很可能在明年晚些时候。但是你可以通过将内置 dockershim 替换为外部 dockershim 来继续使用它。

Docker 和 Mirantis 还同意合作并维护 Kubernetes 之外的 shim 代码,作为 Docker 引擎的一个一致的 CRI 接口。这确保它通过了所有的一致性测试,并像以前的内置版本一样无缝地工作。

为了保持优秀的开发人员体验,Docker 计划继续将这个 shim 发布到 Docker 桌面,而 Mirantis 将在 Mirantis Kubernetes 引擎中利用这个功能。此外,对用 Docker 工具构建的容器映像的 net/net 支持不会被弃用,而且会像以前一样工作。

尽管 Docker 是领先的容器解决方案,但并不是为了嵌入到 Kubernetes 中而开发的。它不仅具有容器运行时功能,还具有多种 UX 增强功能,使开发人员能够与之无缝交互。

Docker 是一个完整的技术堆栈(而不仅仅是一个集装箱化平台),它也提供了称为“containerd”的高级容器运行时,从现在起,这将是您的容器运行时选项。

这些更新和增强功能不一定专注于 Kubernetes。取而代之的是,它们旨在克服障碍,使开发人员能够最大程度地利用障碍。例如,目前,Kubernetes 集群需要一个名为 Dockershim 的工具,该工具已容器化。它用于为团队必须维护的另一种工具增加一定程度的复杂性。但是,它是经常产生错误和其他问题的来源。因此,Kubernetes 项目计划在 1.23 版中删除 Dockershim 并终止对 Docker 的支持。

这意味着问题仅归结为将 Docker 换成 CRI 运行时。但是就目前而言,Docker 开发仍然是相同的没有任何明显的差异。内置 Docker 的映像不是特定于 Docker 的,而是Open Container Initiative (OCI) images。

OCI 是 Docker 在 2015 年建立的,以支持可互操作的容器标准(以确保容器可以在任何环境下运行)。在过去的五年里,它被证明是一个巨大的成功,在促进创新的同时保持互操作性。要使用这些图像,可以使用 containerd 或CRI-O

令人兴奋的新功能

1. CronJobs 和 Kubelet CRI 支持

CronJobs 在 1.4 版中引入,并从 1.5 版开始具有 CRI 支持。但是,尽管被广泛使用,但都没有被认为是稳定的。因此,很高兴看到开发人员所依赖的用于运行生产集群的功能不再被视为 Alpha。

2. CSIServiceAccountToken

此更新通过增强身份验证和令牌处理,大大提高了安全性。现在您可以更安全地访问需要身份验证的卷(包括 secret vaults),设置和部署也要容易得多。

3.公开关注于资源请求和对 Pod 模型的限制的度量

现在有了更多指标可以更好地规划集群的容量,当遇到驱逐问题时,它也有助于排除故障。

4.优雅的节点关闭

虽然它是一个小特性,但它使开发人员的工作变得简单多了。通过在节点关闭时适当释放资源,您现在可以避免奇怪的行为。

5. kube-apiserver 身份标识

每个 kube-apiserver 实例的唯一标识符通常不会被注意到,但这是必要的,因为了解它将有助于确保未来 Kubernetes 版本中的高可用性特性。

6.系统组件日志清理

Kubernetes 系统漏洞最近曝光,尤其是凭证泄漏到日志输出中。牢记大局,现在您可以确定泄漏的潜在来源,并建立编辑机制以消除这些泄漏。

Kubernetes 的系统漏洞最近暴露出来,特别是凭证泄露到日志输出中。现在可以确定泄漏的潜在源,并设置一个修订机制来消除这些漏洞。

应该了解的关键弃用

1. kubeadm 主节点角色更名

阶段:弃用

功能组:集群生命周期

现在将node-role.kubernetes.io/master 更改为 node-role.kubernetes.io/control-plane

2.弃用和禁用 SelfLink

阶段:升级到 Beta

功能组:api-machinery

每个 Kubernetes 对象中的 SelfLink 字段都包含一个表示给定对象的 URL,但不提供任何新信息。同时,它的创建和维护会影响性能。

Kubernetes 1.16 开始弃用,从现在开始,特性门( feature gate)在默认情况下是禁用的,并计划在 Kubernetes 1.21 中删除。

3.流式代理重定向

阶段:弃用

功能组:节点

在 1.18 版中已标记为弃用,StreamingProxyRedirects 和--redirect-container-streaming标志都不会启用。在 1.22 版本中,它也会被默认禁用,而在 1.24 版本中则完全删除。

从上面可以看到,Kubernetes 的开发人员和管理员没有什么可担心的。当他们利用 docker 命令和 kubectl 命令来管理 Kubernetes 集群时,本质上就是业务。

收起阅读 »

影响 Kubernetes 调度的决策因素

本文永久链接: https://www.xtplayer.cn/kubernetes/scheduler/influencing-kubernetes-scheduler-decisions/为了提高节点资源的最大利用率,调度程序使用复杂的算法来确保最有效的 ...
继续阅读 »

本文永久链接: https://www.xtplayer.cn/kubernetes/scheduler/influencing-kubernetes-scheduler-decisions/

为了提高节点资源的最大利用率,调度程序使用复杂的算法来确保最有效的 Pod 调度。在本文中,我们讨论调度程序如何选择最佳节点来运行 Pod,以及如何影响其决策。

哪个节点具有可用资源?

选择适当的节点时,调度程序会检查每个节点是否有足够的资源满足 Pod 调度。如果您已经声明 Pod 所需的 CPU 和内存量(通过请求和限制),调度程序将使用以下公式来计算给定节点上的可用内存:

调度可用内存 = 节点总内存 - 已预留内存

保留内存是指:

  1. Kubernetes 守护进程使用的内存,例如:kubeletcontainerd(一种容器运行时)。
  2. 节点操作系统使用的内存,例如:内核守护程序。

通过使用此方程式,调度程序可确保由于过多 Pod 竞争消耗节点所有可用资源,从而导致节点资源耗尽引起其他系统异常,比如系统触发 oom。

影响调度过程

在不受用户影响的情况下,调度程序在将 Pod 调度到节点时执行以下步骤:

  1. 调度程序检测到已创建新的 Pod,但尚未将其分配给节点;
  2. 它检查 Pod 需求,并相应地筛选出所有不合适的节点;
  3. 根据权重将剩下的节点进行排序,权重最高的排在第一位;
  4. 调度程序选择排序列表中的第一个节点,然后将 Pod 分配给它。

通常,我们会让调度程序自动选择合适的节点(前提是 Pod 配置了资源请求和限制)。但是,有时可能需要通过强制调度程序选择特定节点或手动向多个节点添加权重来影响此决策,以使其比其他节点适合 Pod 调度。

让我们看看我们如何做到这一点:

influncing.jpg

节点名称

在最简单的节点选择配置中,您只需在 .spec.nodeName 中指定其名称,就可以强制 Pod 在指定节点上运行。例如,以下 YAML 定义 Pod 强制在 app-prod01 上进行调度:

YAML
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx
nodeName: app-prod01

请注意,由于以下原因,此方法是最简单但最不推荐的节点选择方法:

  • 如果由于某种原因无法找到指定名称的节点(例如,更改了主机名),则 Pod 将不会运行。
  • 如果该节点没有 Pod 运行所需的资源,则 Pod 会运行失败,并且也不会将该 Pod 调度到其他节点。
  • 这会导致 Pods 与它们的节点紧密耦合,这是一种糟糕的设计实践。

节点选择器

覆盖调度程序决策的第一个最简单的方法是使用 Pod 定义或 Pod 模板(如果使用的是 Deployments 之类的控制器)中的 .spec.nodeSelector 参数。nodeSelector 接受 一个或多个 键-值对标签,这些 键-值对 标签必须在节点设置才能正常的调度 Pod。假设您最近购买了两台配备 SSD 磁盘的计算机,您希望数据库相关所有的 Pod 在 SSD 支持的节点上进行调度,以获得最佳的数据库性能。DB Pod 的 Pod YAML 可能如下所示:

YAML
apiVersion: v1
kind: Pod
metadata:
name: db
spec:
containers:
- name: mongodb
image: mongo
nodeSelector:
disktype: ssd

根据该定义,当调度程序选择合适的 Pod 分配节点时,将仅考虑具有 disktype=ssd 标签的节点。

此外,您可以使用自动分配给节点的任何内置标签来操纵选择决策。例如,节点的主机名(kubernetes.io/hostname),体系结构(kubernetes.io/arch),操作系统(kubernetes.io/os)等均可用于节点选择。

节点亲和性

当您需要选择特定的节点来运行我们的 Pod 时,节点选择非常有用。但是选择节点的方式是有限的,只有与所有定义的标签匹配的节点才被考虑用于 Pod 放置。Node Affinity 通过允许您定义硬节点和软节点需求,为您提供了更大的灵活性。硬性要求必须在要选择的节点上匹配。另一方面,软条件允许您为具有特定标签的节点增加更多权重,以使它们在列表中的位置比对等节点更高。没有软需求标签的节点将不被忽略,但它们权重更小。

让我们举个例子:我们的数据库是 I/O 密集型的。我们需要数据库 Pods 始终在 SSD 支持的节点上运行。此外,如果 Pod 部署在区域 zone1 或 zone2 中的节点上,因为它们在物理上更靠近应用程序节点,那么它们的延迟会更短。满足我们需求的 Pod 定义可能如下所示:

YAML
apiVersion: v1
kind: Pod
metadata:
name: db
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disk-type
operator: In
values:
- ssd
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: zone
operator: In
values:
- zone1
- zone2
containers:
- name: db
image: mongo

nodeAffinity 节使用以下参数来定义硬性要求和软性要求:

  • requiredDuringSchedulingIgnoredDuringExecution:部署 DB Pod 时,节点必须具有 disk-type=ssd。
  • preferredDuringSchedulingIgnoredDuringExecution: 当对节点进行排序时,调度器会给予标签为zone=zone1zone=zone2的节点更高的权重。如果有disk-type=ssdzone=zone1的节点,则优先选择 disk-type=ssd 且无 zone 标签的节点或指向其他 zone 的节点。权重可以是 1 到 100 之间的任意值,权重号赋予匹配节点相对于其他节点更高的权重。数字越大,权值越高。

注意,在进行选择时,节点亲和性允许您在选择目标节点上应该存在(或不存在)哪些标签时拥有更多的自由。在本例中,我们使用 In 操作符定义了多个标签,目标节点上存在任何一个标签即可。其他运算符是 NotIn、Exists、doesnoexistists、Lt(小于)和 Gt(大于)。值得注意的是,NotIn 和 doesnot existist 实现了所谓的节点反亲和性。

节点亲和性和节点选择器不是互斥的,它们可以共存于同一个定义文件中。但是,在这种情况下,节点选择器和节点亲和性硬要求必须匹配。

Pod 亲和性

节点选择器和节点亲和性(以及反亲和性)帮助我们影响调度器关于在何处放置 Pods 的决策。但是,它只允许您基于节点上的标签进行选择。它不关心 Pod 本身的标签。您可能需要在以下情况下根据 Pod 标签进行选择:

  • 需要将所有中间件 Pod 放在同一个物理节点上,与那些具有 role=front 标签的 Pod 一起,以减少它们之间的网络延迟。
  • 作为一种安全最佳实践,我们不希望中间件 Pod 与处理用户身份验证的 Pod 共存(role=auth)。这不是一个严格的要求。

如您所见,这些要求不能用节点选择器或亲和性来满足,因为在选择过程中不考虑 Pod 标签——只考虑节点标签。

为了满足这些需求,我们使用 Pod 亲和性和反亲和性。本质上,它们的工作方式与节点亲和性和反亲和性相同。必须满足硬性要求来选择目标节点,而软条件增加了拥有所选节点的机会(权重),但不是严格要求。让我们举个例子:

YAML
apiVersion: v1
kind: Pod
metadata:
name: middleware
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: role
operator: In
values:
- frontend
topologyKey: kubernetes.io/hostname
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: role
operator: In
values:
- auth
topologyKey: kubernetes.io/hostname
containers:
- name: middleware
image: redis

在上面的 Pod 定义文件中,我们对硬性要求和软性要求进行了如下设置:

requiredDuringSchedulingIgnoredDuringExecution:我们的 Pod 必须在具有标签为 app-front 的 Pod 节点上调度。

preferredDuringSchedulingIgnoredDuringExecution:我们的 Pod 不应该(但它可以)被调度到运行带有标签为 role=auth 的 Pod 的节点上。与节点亲和性一样,soft requirement 将权重从 1 设置为 100,以增加节点相对于其他节点的概率。在我们的示例中,软需求被放置在 poantiaffinity 中,导致运行具有标签为 role=auth 的 Pod 的节点在调度程序做出决定时被选中的可能性更小。

topologyKey 用于对规则将应用于哪个领域做出更细粒度的决策。topologyKey 接受一个标签键,该标签键必须出现在选择过程中考虑的节点上。在我们的示例中,我们使用了自动填充的标签,该标签在默认情况下自动添加到所有节点,并引用节点的主机名。但是您可以使用其他自动填充的标签,甚至是自定义的标签。例如,您可能需要只在具有 rack 或 zone 标签的节点上应用 Pod 亲和规则。

关于 IgnoredDuringExecution 的注释

您可能已经注意到,硬需求和软需求都有 IgnoredDuringExecution 后缀。这意味着在做出调度决策之后,调度程序将不会尝试更改已经放置的 Pods,即使条件发生了变化。例如,根据节点亲和性规则,将一个 Pod 调度到一个具有标签为 app=prod 的节点上。如果该标签被更改为 app=dev, 旧 Pod 不会被终止,并在另一个有 app=prod 标签的节点上启动新的 Pod。这个行为在将来可能会改变,以允许调度程序在部署后继续检查节点和 Pod 的关联性(和反关联性)规则。

污点与容忍

在某些场景中,您可能希望阻止将 Pod 调度到特定节点。可能您正在运行测试或扫描此节点以查找威胁,而您不希望应用程序受到影响。节点反亲和性可以实现这一目标。但是,这是一个重大的管理负担,因为您需要向部署到集群的每个新 Pod 添加反关联规则。对于这种场景,您应该使用污点。

当一个节点配置了污点时,除非 Pod 能够容忍这种污点,否则不能对它调度 Pod。容忍只是一个与污点匹配的键-值对。让我们举个例子来说明:

需要对主机 web01 进行污染,以使其不接受更多 Pod。taint 命令如下:

YAML
kubectl taint nodes web01 locked=true:NoSchedule

上面的命令在名为 web01 的节点上放置了一个污点,该节点具有以下属性:

  • 标签 locked=true,该标签必须配置在想要运行在该节点的 Pod 上。

  • NoSchedule 的污点类型。污点类型定义了应用污点的行为,它有以下几种可能:

    • NoSchedule:此节点一定不要调度。
    • PreferNoSchedule:尽量不要调度,类似软亲和性。
    • NoExecute:不仅不会调度,还会驱逐 Node 上已有的 Pod。

在带有污点的节点上,Pod 的定义文件可能如下所示:

YAML
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mycontainer
image: nginx
tolerations:
- key: "locked"
operator: "Equal"
value: "true"
effect: "NoSchedule"

让我们仔细看看这个定义的容忍部分:

  • 为了具有正确的容忍,我们需要指定键(locked),值(true)和运算符。

  • 运算符可以是两个值之一:

    • Equal:当使用 equal 操作符时,键、值和污染效果必须与节点的污染匹配。
    • Exists:在使用 exists 操作符时,不需要将污点与容忍匹配,只需匹配建即可。
  • 如果使用 Exists 运算符,则可以忽略容忍键、值和效果。具有这种容忍的 Pod 可以被调度到具有任何受污点的节点。

注意,在 Pod 上放置容忍并不能保证它被部署到受污染的节点上。它只允许行为发生。如果要强制 Pod 加入受污染的节点,还必须像前面讨论的那样向其定义添加节点亲和性。

TL; DR

在节点上自动放置 Pod 是 Kubernetes 诞生的原因之一。作为管理员,只要您对 Pod 需求做出了良好的声明,您就不用担心节点是否有足够的空闲资源来运行这些 Pod。但是,有时您必须手动干预和覆盖系统关于在何处放置 Pods 的决定。在本文中,我们讨论了几种方法,在决定部署 Pods 时,您可以通过这些方法对特定节点的调度器产生更大的影响。让我们快速回顾一下这些方法:

  • 节点名称:通过将节点的主机名添加到 Pod 定义的 .spec.nodeName 参数中,可以强制此 Pod 在该特定节点上运行。调度程序使用的任何选择算法都将被忽略。不建议使用此方法。
  • 节点选择器:通过在节点上放置指定的标签,Pod 可以使用 nodeelector 参数指定一个或多个键-值标签,这些标签必须存在于目标节点上才能被选中以运行 Pod。推荐使用这种方法,因为它增加了很多灵活性,并建立了松耦合的 node-Pod 关系。
  • 节点亲和性:在选择应该考虑哪个节点来调度特定的 Pod 时,这种方法增加了更多的灵活性。使用节点亲和性,Pod 可能严格要求在具有特定标签的节点上调度。它还可以通过影响调度程序为特定节点赋予更大的权重来表示对特定节点的某种程度的偏好。
  • Pod 亲和性和反亲和性:当 Pod 与同一节点上的其他 Pod 共存(或不共存)时,可以使用此方法。Pod 亲和性允许将 Pod 部署在具有特定标签的 Pod 运行的节点上。相反,Pod 可能会强制调度程序不将其调度到具有特定标签的 Pod 运行的节点上。
  • 污点和容忍:在这种方法中,您不需要决定将 Pod 调度到哪些节点,而是决定哪些节点是否接受 所有 Pod 调度,或者只接受选定的 Pod 调度。通过污染一个节点,调度程序将不考虑将这个节点作为任何 Pod 的调度节点,除非 Pod 配置了容忍。容忍由键、值和受染的效果组成。

原文链接:https://www.magalix.com/blog/influencing-kubernetes-scheduler-decisions

收起阅读 »

初步了解 Kubernetes 基础功能

本文永久链接: https://www.xtplayer.cn/kubernetes/kubernetes-basics/什么是 Kubernetes?随着越来越多的组织开始采用容器,以容器为中心的管理软件 Kubernetes 已成为部署和操作容器化应用的通...
继续阅读 »

本文永久链接: https://www.xtplayer.cn/kubernetes/kubernetes-basics/

什么是 Kubernetes?

随着越来越多的组织开始采用容器,以容器为中心的管理软件 Kubernetes 已成为部署和操作容器化应用的通行标准。Google Cloud 是 Kubernetes 诞生的地方 - Kubernetes 最初在 Google 开发,然后在 2014 年开源发布。Kubernetes 的构建以 15 年来运行 Google 的容器化工作负载的经验以及开源社区的宝贵贡献为依托。Kubernetes 受 Google 内部集群管理系统 Borg 的启发,能够简化与部署和管理应用相关的所有工作。Kubernetes 可提供自动化容器编排,因此能够提高可靠性,同时节省日常运营所需的时间和资源。

Kubernetes 的定义

Kubernetes(有时简写为“K8s”,其中“8”代表“K”和“s”之间的 8 个字母)是一个开源系统,支持在任何地方部署、扩缩和管理容器化应用。

Kubernetes 可自动执行容器管理的操作任务,其内置了用于部署应用、更改应用、根据不断变化的需求扩缩应用、监控应用等的命令,以便更轻松地管理应用。

Kubernetes 有哪些优势?

自动化运营

Kubernetes 具有许多内置命令,可用于处理应用管理中繁重的工作,从而自动化日常操作,帮助您确保应用始终按照预期的方式运行。

基础架构抽象

安装 Kubernetes 后,它将代表您的工作负载处理计算、网络和存储。这使开发者可以专注于应用,而不必担心底层环境。

服务运行状况监控

Kubernetes 会对您的服务不间断地执行运行状况检查,重新启动有故障或停滞的容器,且只会在确认服务正常运行时向用户提供服务。

Kubernetes 与 Docker 的区别

Kubernetes 和 Docker 通常被误认为只能二选一,其实它们都是用于运行容器化应用的技术,彼此不同但相互补充。Docker 可以将运行应用所需的一切资源放入一个箱子中,这个箱子可以存储起来并在需要的时间和位置打开。将应用装箱后,就需要一种方法来管理它们,这就是 Kubernetes 的作用。Kubernetes 是希腊语,意思是 “船长”。就像船长负责船舶在海上的安全航行一样,Kubernetes 负责安全运送这些箱子并将其交付到可以使用的地点。Kubernetes 可以和 Docker 搭配使用,也可以独立使用 Docker 并不是 Kubernetes 的替代品,因此其实也不存在 “Kubernetes 与 Docker 的区别” 这个问题。将 Kubernetes 与 Docker 结合使用可以容器化您的应用,并大规模运行它们 Docker 和 Kubernetes 之间的差异与它们在容器化和运行应用中所扮演的角色有关 Docker 是在容器中打包和分发应用的开放式业界标准 Kubernetes 使用 Docker 来部署、管理和扩缩容器化应用

Kubernetes 有哪些用途?

Kubernetes 用于创建易于在任何地方管理和部署的应用。当作为代管式服务时,Kubernetes 可为您提供一系列解决方案以满足您的需求。以下是一些常见使用场景。

提高开发速度

Kubernetes 可帮助您构建基于微服务的云原生应用。它还支持容器化现有应用,为应用现代化改造奠定基础,帮助您更快地开发应用。

在任何地方部署应用

Kubernetes 可以在任何地方使用,让您可以在本地部署、公有云部署以及混合部署之间运行应用。因此,您可以在任何需要的地方运行您的应用。

运行高效的服务

Kubernetes 可以自动调整运行服务所需集群的大小。这使您可以根据需求自动扩缩并高效运行应用。

Kubernetes 能为您做什么?

通过现代的 Web 服务,用户希望应用程序能够 24/7 全天候使用,开发人员希望每天可以多次发布部署新版本的应用程序。 容器化可以帮助软件包达成这些目标,使应用程序能够以简单快速的方式发布和更新,而无需停机。Kubernetes 帮助您确保这些容器化的应用程序在您想要的时间和地点运行,并帮助应用程序找到它们需要的资源和工具。Kubernetes 是一个可用于生产的开源平台,根据 Google 容器集群方面积累的经验,以及来自社区的最佳实践而设计。

Kubernetes 基础模块

1. 创建 k8s 集群2. 部署应用       
module_01.svgmodule_02.svg
3. 探索您的应用4. 发布应用       
module_03-20210213225613100.svgmodule_04.svg
5. 伸缩应用6. 更新应用       
module_05.svgmodule_06.svg
收起阅读 »

Rancher 常见问题集锦

本文永久链接: https://www.xtplayer.cn/rancher/rancher-problem-sets/Rancher server 管理员密码重置请查参考链接:Rancher server 管理员密码重置Rancher server 如何数...
继续阅读 »

本文永久链接: https://www.xtplayer.cn/rancher/rancher-problem-sets/

Rancher server 管理员密码重置

请查参考链接:Rancher server 管理员密码重置

Rancher server 如何数据持久?

Rancher server 不管是单节点单容器安装,或者是多节点 Local kubernetes HA 安装,Rancher server 都是通过 kubernetes API 去写入数据,最后数据都是保存在 kubernetes 后端的数据存储服务中(etcd)。

在 v2.3.x 之前的 Rancher server 版本中,Rancher server 容器中运行了一个定制化的微型 kubernetes 集群。在 v2.3.x 及之后的 Rancher server 版本中,定制化的微型 kubernetes 集群更换成了 K3S 集群。

  • Rancher server 单节点单容器安装

对于单节点单容器安装的 Rancher server,容器中的定制化微型 kubernetes 集群或者 K3S 集群会一并启动,然后 Rancher server 会去访问微型 kubernetes 集群或者 K3S 集群的 API 地址进行数据的读写,默认数据文件保存在容器的 /var/lib/Rancher 路径下。可以将此目录挂载到主机主机的某个位置,以保证数据不会丢失。

  • Rancher server HA 安装

Local kubernetes 集群 Rancher server HA 安装,这种安装模式下 Rancher server 也是通过 Local kubernetes 集群的 API 地址进行数据读写,通过 Local kubernetes,数据被直接写入到了 kubernetes 后端的 ETCD 服务中。

Rancher server 单节点单容器安装场景下,如何在同一个主机上运行 Rancher server 和 Rancher-Agent?

默认情况下,Rancher 中创建的 kubernetes 集群,会在所有可调度的节点上安装 ingress 控制器服务。ingress 控制器服务默认是 host 网络模式,并且 ingress 控制器服务默认监听了 80 和 443 端口。

因此,如果 Rancher server 单节点单容器安装时是通过 -p 80:80 -p 443:443 映射的容器端口,那么如果把 ranche server 所在的主机添加到 kubernetes 后将会出现端口冲突的问题。

针对这个问题,我们有两种方法处理:

  1. 修改 Rancher server 容器映射的端口。

    注意:如果集群已经创建好,此时修改映射端口将会导致 agent 服务无法访问 Rancher server。如果必须要修改映射端口,请参考文章进行处理:https://www.xtplayer.cn/rancher/replace-ip-domain/

  2. 修改 ingress 控制器的默认监听端口

    修改 ingress 控制器工作负载的 YAML 文件,在 args 参数中插入 --http-port=8880 --https-port=8443,或者在 Rancher ui 上修改,具体参考文档:自定义 http 和 https 端口 。

删除或者停用了管理员,该如何恢复?

  1. 单节点安装

    BASH
    docker exec -ti <container_id> ensure-default-admin
    New default admin user (user-xxxxx)
    New password for default admin user (user-xxxxx):
    <new_password>
  2. HA 安装

    HA 安装恢复方法与单节点安装方法相同,只是在 HA 安装架构下,一般是有多个 Rancher server Pod,所以需要先把 Rancher server Pod 数量缩减为 1,然后再按单节点安装恢复方法处理即可。

怎么样开启 Debug 模式?

  • 单节点安装

    1. 启用

      BASH
      docker exec -ti <container_id> loglevel --set debug
      OK
      docker logs -f <container_id>
    2. 禁用

      BASH
      docker exec -ti <container_id> loglevel --set info
      OK
  • HA 安装

    HA 安装启用 Debug 与 单节点安装启用 Debug 模式相同,只需在要启用的 Pod 中运行命令。

ClusterIP 无法 ping 通?

  • 在 kube-proxy 使用 iptables 的 kubernetes 集群中,ClusterIP 是一个虚拟 IP,不会响应 ping,它仅作为 iptables 转发的目标规则。测试 ClusterIP 配置是否正确的最好方法是使用curl来访问 Pod IP 和端口以查看它是否响应。

  • 在 kube-proxy 使用 ipvs 的 kubernetes 集群中,ClusterIP 可以 ping 通。

为什么 L4 层负载均衡 svc 处于“挂起”状态?

L4 层负载均衡器创建为 type:LoadBalancer,在 Kubernetes 中,这需要云提供商或控制器能够满足这些请求,否则这些将永远处于“挂起”状态。 了解更多 云提供商 或者 Create External Load Balancer

节点的 IP 地址发生了变化,该如何恢复?

节点需要配置静态 IP(或通过 DHCP 保留 IP)。如果节点的 IP 已更改,则必须将其从集群中删除。删除后,Rancher 会将集群更新为正确的状态。如果集群不再处于 Provisioning 状态,则已经从集群中删除该节点。当节点的 IP 地址发生变化时,Rancher 失去了与节点的连接,因此无法正常清理节点。请参阅 清理集群节点 以清除节点。

从集群中删除节点并清除节点后,您可以将节点重新添加到集群。

如何查询 ssl 证书与域名或者 IP 的对应关系?

通过以下命令可以查看到 ssl 证书绑定的域名或者 ip。

BASH
openssl x509 -noout -in cert.pem -text | grep DNS

404 - default backend

收起阅读 »

kubernetes secret device or resource busy

本文永久链接: https://www.xtplayer.cn/kubernetes/kubernetes-secret-device-or-resource-busy/如上图,有时候升级业务 Pod 时,旧业务 Pod 一直处于 removing 状态。在主...
继续阅读 »

本文永久链接: https://www.xtplayer.cn/kubernetes/kubernetes-secret-device-or-resource-busy/

image-20210129165812618.png

如上图,有时候升级业务 Pod 时,旧业务 Pod 一直处于 removing 状态。在主机上执行 docker ps -a | grep <pod 名称> 也未能查询到残留容器。登录 Pod 所在的主机,执行 docker logs kubelet --tail 100 查看 kubelet 的运行日志,可以看到以下错误日志:

BASH
Error: "UnmountVolume.TearDown failed for volume \"default-token-r9sxw\"
(UniqueName: \"kubernetes.io/secret/bc895c3f-2fbf-11eb-a93a-4cd98f444b4d-default-token-r9sxw\") pod \"bc895c3f-2fbf-11eb-a93a-4cd98f444b4d\" (UID: \"bc895c3f-2fbf-11eb-a93a-4cd98f444b4d\") :
remove /var/lib/kubelet/pods/bc895c3f-2fbf-11eb-a93a-4cd98f444b4d/volumes/kubernetes.io~secret/default-token-r9sxw: device or resource busy"

处理方法

  1. 指定占用的路径

    BASH
    path=/var/lib/kubelet/pods/bc895c3f-2fbf-11eb-a93a-4cd98f444b4d/volumes/kubernetes.io~secret/default-token-r9sxw
  2. 查找占用路径的进程 pid 号。

    通过以下命令可以查询到占用上面路径的 pid 号。

    BASH
    find /proc/*/mounts -exec grep ${path} {} +

    应该会得到类似以下的结果,/proc/ 与 /mounts 中间则为进程 pid 号。

    BASH
    /proc/9706/mounts /var/lib/kubelet/pods/bc895c3f-2fbf-11eb-a93a-4cd98f444b4d/volumes/kubernetes.io~secret/default-token-r9sxw
  3. 根据上一步中查询到的 pid 号,接着执行以下命令查看具体是什么进程占用

    BASH
    ps -ef | grep <pid 号>
收起阅读 »

记一次 request_sock_tcp possible syn flooding on port 事件处理

本文永久链接: https://www.xtplayer.cn/linux/network/request-sock-tcp-possible-syn-flooding-on-port/TCP 三次握手客户端发送 SYN(进入 SYNC_SENT 状态)服务端...
继续阅读 »

本文永久链接: https://www.xtplayer.cn/linux/network/request-sock-tcp-possible-syn-flooding-on-port/

TCP 三次握手

  1. 客户端发送 SYN(进入 SYNC_SENT 状态)

  2. 服务端返回 SYN+ACK(进入 SYNC_RECV 状态)

  3. 客户端发送 ACK(进入 ESTABLISHED 状态)

如果客户端在第 3 步时不发送 ACK 给服务端,那么服务端的 socket 就会处于 SYNC_RECV 状态。

TCP/IP backlog 参数

backlog 其实是一个连接队列,在 Linux kernel 2.2 之前,backlog 大小包括半连接状态和全连接状态两种队列大小。

  • 半连接状态为:服务器处于 Listen 状态时收到客户端 SYN 报文时放入半连接队列中,即 SYN queue(服务器端口状态为:SYN_RCVD)。

  • 全连接状态为:TCP 的连接状态从服务器(SYN+ACK)响应客户端后,到客户端的 ACK 报文到达服务器之前,则一直保留在半连接状态中。当服务器接收到客户端的 ACK 报文后,该条目将从半连接队列搬到全连接队列尾部,即 accept queue(服务器端口状态为:ESTABLISHED)。

在 Linux kernel 2.2 之后,分离为两个 backlog 来分别限制半连接(SYN_RCVD 状态)队列大小和全连接(ESTABLISHED 状态)队列大小。

SYN queue 队列长度由 /proc/sys/net/ipv4/tcp_max_syn_backlog 指定,默认为 2048。

Accept queue 队列长度由 /proc/sys/net/core/somaxconn 和使用 listen 函数时传入的参数,二者取最小值,默认为 128。在 Linux kernel 2.4.25 之前,是写死在代码常量 SOMAXCONN 。在 Linux kernel 2.4.25 之后,在配置文件 /proc/sys/net/core/somaxconn 中直接修改,或者在 /etc/sysctl.conf 中配置 net.core.somaxconn = 128

927655-20161215133843776-605308204.png
  • 可以通过 ss 命令来显示
BASH
[root@localhost ~]# ss -l
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *:http *:*
LISTEN 0 128 :::ssh :::*
LISTEN 0 128 *:ssh *:*
LISTEN 0 100 ::1:smtp :::*
LISTEN 0 100 127.0.0.1:smtp *:*

在 LISTEN 状态,其中 Send-Q 即为 Accept queue 的最大值,Recv-Q 则表示 Accept queue 中等待被服务器 accept()。

另外客户端 connect() 返回不代表 TCP 连接建立成功,有可能此时 accept queue 已满,系统会直接丢弃后续 ACK 请求。客户端误以为连接已建立,开始调用等待至超时,服务器则等待 ACK 超时,会重传 SYN+ACK 给客户端,重传次数由 net.ipv4.tcp_synack_retries 限制,默认为 5 ,表示重发 5 次,每次等待 30~40 秒,即半连接默认时间大约为 180 秒,可以在 tcp 被洪水攻击是临时启用这个参数。

  • 查看 SYN queue 溢出
BASH
[root@localhost ~]# netstat -s | grep LISTEN
102324 SYNs to LISTEN sockets dropped
  • 查看 Accept queue 溢出
BASH
[root@localhost ~]# netstat -s | grep TCPBacklogDrop
TCPBacklogDrop: 2334

排查步骤

此处省略排查步骤。

内核调优

根据 TCP 三次握手 和 TCP/IP backlog 参数 可以知道通过调节内核的一些参数可以解决队列溢出的问题。

BASH
# vim /etc/sysctl.conf
net.core.somaxconn = 2048
net.ipv4.tcp_max_syn_backlog = 81920
net.ipv4.tcp_syncookies = 1
net.core.netdev_max_backlog = 1000

# 保存退出后,执行:sysctl -p

问题再次重现

正常情况,当内核参数经过调优后,SYN flooding 的问题即可解决。但是当内核参数经过调优后,查看系统日志依然有 request_sock_tcp possible syn flooding on port

后期经过查阅资料发现,The application's socket listen backlog is applied when the application makes the listen() system call against its socket.,也就是在程序通过 listen() 系统调用时,可以对 socket listen backlog 做限制。

会不会是程序限制的 backlog 太小,导致队列溢出呢?通过查看程序代码,果然是 backlog 太小导致的。通过调整程序的 backlog 大小 request_sock_tcp possible syn flooding on port 不再出现。

参考链接

https://access.redhat.com/solutions/30453


收起阅读 »

Linux Netfilter 调优

本文永久链接: https://www.xtplayer.cn/linux/netfilter/linux-netfilter-optimization/如果您正在为高流量的 Web/DNS 服务器提供服务,并且最近使该服务器 PING 丢失并且并非所有 HT...
继续阅读 »


本文永久链接: https://www.xtplayer.cn/linux/netfilter/linux-netfilter-optimization/

如果您正在为高流量的 Web/DNS 服务器提供服务,并且最近使该服务器 PING 丢失并且并非所有 HTTP 请求都成功。您可以开始检查系统日志。并且如果您看到类似下面的内容,那么下面的指南将帮助您调整 Linux 服务器以正确处理流量负载。

BASH
Mar 22 21:25:55 localhost kernel: nf_conntrack: table full, dropping packet.
Mar 22 21:26:00 localhost kernel: printk: 11 messages suppressed.
Mar 22 21:26:00 localhost kernel: nf_conntrack: table full, dropping packet.
Mar 22 21:26:05 localhost kernel: printk: 16 messages suppressed.

状态查看

  • buckets 哈希表大小,max 最大记录的连接条数

    BASH
    sudo dmesg | grep conntrack

    [ 8.782060] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
  • 哈希表使用情况

    BASH
    grep conntrack /proc/slabinfo

    nf_conntrack_1 102 102 320 51 4 : tunables 0 0 0 : slabdata 2 2 0
  • 当前跟踪的连接数

    BASH
    sudo sysctl net.netfilter.nf_conntrack_count
  • 跟踪连接详细信息

    BASH
    # centos
    cat /proc/net/nf_conntrack
    # ubuntu,可能需要安装 conntrack 工具,yum install -y conntrack 或者 apt-getinstall -y conntrack
    conntrack -L

    最大连接跟踪数

为了完成任务,NAT-server(一般指的是 iptables) 需要记录所有通过它的连接。无论是 “ping” 还是某人的 “ICQ”,NAT-server 都会记录在一个特殊的表中并跟踪所有会话。当会话关闭时,相关记录将从连接跟踪表中删除。这个记录表的大小是固定的,所以如果通过服务器的流量很大,但表太小,那么 NAT-server 就会开始丢弃数据包,中断会话。为了避免这样的麻烦,有必要适当增加连接跟踪表的大小。

  • 最大连接跟踪数默认为 *nf_conntrack_buckets * 4*,可以通过以下命令查看当前值:

    BASH
    sysctl net.netfilter.nf_conntrack_buckets
    sysctl net.netfilter.nf_conntrack_max
  • CONNTRACK_MAX 默认计算公式

    BASH
    CONNTRACK_MAX = 内存个数*1024*1024*1024/16384/(ARCH/32)
    • 其中 ARCH 为 CPU 架构,值为 32 或 64。
    • 比如:64 位 8G 内存的机器:(8*1024^3)/16384/(64/32) = 262144

临时调整

临时调整是临时性的,重启节点好配置值将会丢失。

BASH
sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.nf_conntrack_max=1048576

永久调整

要使其配置在重新启动后永久存在,需要将这些值添加到 sysctl.conf 中

BASH
echo 'net.netfilter.nf_conntrack_max' = 1048576 >> /etc/sysctl.conf
echo 'net.nf_conntrack_max = 1048576' >> /etc/sysctl.conf
sysctl -p

如果服务器中的 RAM 少于 1 GB,建议不要设置太大的值。

哈希表(hash-table)

哈希表大小是只读的,不能在 /etc/sysctl.conf 文件中设置值。64 位 Linux 系统中,4G 内存默认 16384,8G 内存默认 65536,16G 翻倍,以此类推。

给哈希表扩容的影响

主要是内存使用增加,32 位系统还要关心内核态的地址空间够不够。

netfilter 的哈希表存储在内核态的内存空间,这部分内存不能 swap,操作系统为了兼容 32 位,默认值往往比较保守。

  • 32 位系统的虚拟地址空间最多 4G,其中内核态最多 1G,通常能用的只有前 896M。

    给 netfilter 分配太多地址空间可能会导致其他内核进程不够分配。1 条跟踪记录 300 字节左右,因此当年 nf_conntrack_max 默认 65535 条,占 20 多 MB。

  • 64 位系统的虚拟地址空间有 256 TB,内核态能用一半,只需要关心物理内存的使用情况。

  • 计算内存使用的公式

    BASH
    size_of_mem_used_by_conntrack (in bytes) = CONNTRACK_MAX * sizeof(struct ip_conntrack) + HASHSIZE * sizeof(struct list_head)
    • sizeof(struct ip_conntrack) 在不同架构、内核版本、编译选项下不一样。这里按 352 字节算。

    • sizeof(struct list_head) = 2 * size_of_a_pointer(32 位系统的指针大小是 4 字节,64 位是 8 字节)

    • 64 位系统,8G 内存的机器,按默认 CONNTRACK_MAX 为 262144,HASHSIZE 为 65536 时:262144 * 352 + 65536 * 8 = 92798976(88.5 MB)

  • 互联网公司的服务器通常内存没那么紧张,可以放开点:

    • CONNTRACK_MAX 为 1048576,HASHSIZE 为 262144 ,内存大概使用:1048576 * 352 + 262144 * 8 = 371195904(354 MB)

哈希表大小调整

需要通过内核模块的方式修改:

  • 临时生效:

    BASH
    echo 262144 > /sys/module/nf_conntrack/parameters/hashsize
  • 永久生效

    将以下内容添加到文件:/etc/modprobe.d/iptables.conf(如果没有则新建)

    echo 'options nf_conntrack hashsize=262144' >> /etc/modprobe.d/iptables.conf

减少超时时间

NAT-server 只跟踪通过它的 活动 的会话。如果一个会话很长时间是空闲的,不活跃,它将会因为超值而被关闭。当会话关闭时,关于它的信息将被删除,以便连接跟踪表不会溢出。

但是,如果超时的默认值很大,流量较大时候,即使将 nf_conntrack_max 扩展到了极限,跟踪表仍然有溢出的风险。为此,必须在 NAT-server 上正确设置连接跟踪超时。

可以执行以下命令查看默认值:

sysctl -a | grep conntrack | grep timeout

  • Ubuntu 16.04

    BASH
    net.netfilter.nf_conntrack_generic_timeout = 600
    net.netfilter.nf_conntrack_icmp_timeout = 30
    net.netfilter.nf_conntrack_tcp_timeout_close = 10
    net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
    net.netfilter.nf_conntrack_tcp_timeout_established = 432000
    net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
    net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
    net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
    net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
    net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
    net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
    net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
    net.netfilter.nf_conntrack_udp_timeout = 30
    net.netfilter.nf_conntrack_udp_timeout_stream = 180
  • centos 7.8

    BASH
    net.netfilter.nf_conntrack_dccp_timeout_closereq = 64
    net.netfilter.nf_conntrack_dccp_timeout_closing = 64
    net.netfilter.nf_conntrack_dccp_timeout_open = 43200
    net.netfilter.nf_conntrack_dccp_timeout_partopen = 480
    net.netfilter.nf_conntrack_dccp_timeout_request = 240
    net.netfilter.nf_conntrack_dccp_timeout_respond = 480
    net.netfilter.nf_conntrack_dccp_timeout_timewait = 240
    net.netfilter.nf_conntrack_events_retry_timeout = 15
    net.netfilter.nf_conntrack_generic_timeout = 600
    net.netfilter.nf_conntrack_icmp_timeout = 30
    net.netfilter.nf_conntrack_sctp_timeout_closed = 10
    net.netfilter.nf_conntrack_sctp_timeout_cookie_echoed = 3
    net.netfilter.nf_conntrack_sctp_timeout_cookie_wait = 3
    net.netfilter.nf_conntrack_sctp_timeout_established = 432000
    net.netfilter.nf_conntrack_sctp_timeout_heartbeat_acked = 210
    net.netfilter.nf_conntrack_sctp_timeout_heartbeat_sent = 30
    net.netfilter.nf_conntrack_sctp_timeout_shutdown_ack_sent = 3
    net.netfilter.nf_conntrack_sctp_timeout_shutdown_recd = 0
    net.netfilter.nf_conntrack_sctp_timeout_shutdown_sent = 0
    net.netfilter.nf_conntrack_tcp_timeout_close = 10
    net.netfilter.nf_conntrack_tcp_timeout_close_wait = 3600
    net.netfilter.nf_conntrack_tcp_timeout_established = 86400
    net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
    net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
    net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
    net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
    net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
    net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
    net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
    net.netfilter.nf_conntrack_udp_timeout = 30
    net.netfilter.nf_conntrack_udp_timeout_stream = 180

    以上均是以秒为单位的超时值。

对于通外网的服务器,考虑调整以下参数,减少 DDoS 的危害:

  • net.netfilter.nf_conntrack_tcp_timeout_established:默认 432000(5 天)

    • 这个值对应的场景是 “双方建立了连接后一直不发包,直到 5 天后才发”
    • 但默认 keep-alive 超时时间只有 2 小时 11 分(net.ipv4.tcp_keepalive_time + net.ipv4.tcp_keepalive_intvl * net.ipv4.tcp_keepalive_probes),由于超时关 socket 不发包,conntrack 无法根据包头的标识知道状态的变化,记录会一直处于 ESTABLISHED 状态,直到 5 天后倒计时结束才删掉。
    • 空连接攻击的最佳目标。攻击者把 IP 包头的源地址改成随机 IP,握完手就关 socket,用一台机发请求就能把你的哈希表填满。
  • net.netfilter.nf_conntrack_tcp_timeout_syn_recv:默认 60

    • 类似,故意不发握手的 ACK 即可。但这个超时时间没那么夸张,系统也有 syn cookie 机制来缓解 syn flood 攻击。

其他值得注意的参数:

  • net.netfilter.nf_conntrack_tcp_timeout_syn_sent:默认 120

    • 你的程序的 connect timeout 有这么长吗?
  • net.netfilter.nf_conntrack_tcp_timeout_fin_wait:默认 120

    • net.ipv4.tcp_fin_timeout 默认 60 秒,通常还会参考 BSD 和 macOS 设成更小的值。这里往往也没必要这么大。
  • net.netfilter.nf_conntrack_icmp_timeout:默认 30

    • 哪里的 ping 会等 30 秒才超时?

这几个倒是比较合理,小于等于可能遇到的极端情况,但如果不想半关闭的连接的记录继续占着宝贵的哈希表,提早清了似乎也没什么问题:

  • net.netfilter.nf_conntrack_tcp_timeout_time_wait:默认 120

    • Linux 里的 MSL 写死 60 秒(而不是 TCP 标准里拍脑袋的 120 秒),TIME_WAIT 要等 2MSL,这里 120 算是个合理的值。
    • 但现在默认有 PAWS(net.ipv4.tcp_timestamps),不会出现标准制定时担心的迷途报文回来碰巧污染了序列号相同的新连接的数据的情况。互联网公司基本都开 net.ipv4.tcp_tw_reuse,既然半连接都不留这么久,记录似乎也不需要留这么久。
  • net.netfilter.nf_conntrack_tcp_timeout_close_wait:默认 60

    • CLOSE_WAIT 状态是让被动关闭方把该传的数据传完。如果程序写得不好,这里抛了未捕捉的异常,也许就走不到发 FIN 那步了,一直停在这里。
  • net.netfilter.nf_conntrack_tcp_timeout_last_ack:默认 30

    • 被动关闭方发 FIN 后如果一直收不到对面的 ACK 或 RST,会不断重发,直到超时才 CLOSE。net.ipv4.tcp_retries2 的默认值是 15,最多要等 924.6 秒……不过一般都会调小这个值。

调整参数

添加以下配置参数到 /etc/sysctl.conf 文件,最后执行 sysctl -p

BASH
net.netfilter.nf_conntrack_icmp_timeout=10
net.netfilter.nf_conntrack_tcp_timeout_syn_recv=5
net.netfilter.nf_conntrack_tcp_timeout_syn_sent=5
net.netfilter.nf_conntrack_tcp_timeout_established=600
net.netfilter.nf_conntrack_tcp_timeout_fin_wait=10
net.netfilter.nf_conntrack_tcp_timeout_time_wait=10
net.netfilter.nf_conntrack_tcp_timeout_close_wait=10
net.netfilter.nf_conntrack_tcp_timeout_last_ack=10

参考链接

https://testerhome.com/topics/15824
https://www.cnblogs.com/xiangsikai/p/9525287.html

收起阅读 »

rancher k8s 对接 ceph 存储

原文链接:https://www.xtplayer.cn/kubernetes/storage/k8s-storage-ceph/ 本文编写的前提是已有正常工作的 ceph 存储服务,并且 Rancher 集群能正常访问 ceph 存储服务,另外这里我们对接的...
继续阅读 »

原文链接:https://www.xtplayer.cn/kubernetes/storage/k8s-storage-ceph/


本文编写的前提是已有正常工作的 ceph 存储服务,并且 Rancher 集群能正常访问 ceph 存储服务,另外这里我们对接的是 Rancher 持久化存储的存储类。\


随着 UI 翻译的更新,可能有些参数名称与实际名称不相同。


配置 ceph secret

Rancher 连接 ceph 集群需要 ceph secret,在 ceph 服务器中执行以下命令生成 ceph secret:


BASH
ceph auth get-key client.admin |base64

clip_image002.png


创建 secret 对象

将 key 替换为实际 ceph 的 secret,然后 import yaml 到 rancher 集群。


BASH
apiVersion: v1
kind: Secret
metadata:
type: “kubernetes.io/rbd”
data:
key: QVFEMDJ1VmE0L1pxSEJBQUtTUnFwS3JFVjErRjFNM1kwQ2lyWmc9PQ==

clip_image003.png


UI 配置存储类


  1. 进入集群视图,在存储菜单下选择存储类
    clip_image004.png
  2. 设置存储名称,并选择 ceph-rbd 类
    image-20181111221714979.pngclip_image005.png
  3. 配置 ceph-rbd 参数,填写对应的 ceph-monitor 地址和管理员 ID (), 还有 secret-name



    • 监控:ceph-monitor 地址


    • 管理员 ID:ceph-monitor 登录账户


    • 管理密文命名空间:管理密文导入的命名空间,根据实际导入的命名空间填写
      clip_image006.png



  4. 点击页面最下方的保存
    clip_image007.png

创建应用并挂载数据卷

方法一:手动创建卷再挂载


  1. 切换到项目视图,依次点击工作负载 / 数据卷 / 添加卷
    image-20181111224750914.png
  2. 填写卷配置信息,比如选择对应的存储类和卷的大小
    clip_image008.png
  3. 点击页面下方的创建
    clip_image009.png
  4. 创建工作负载,选择对应的存储卷和挂载的目录
    clip_image010.pngclip_image011.pngclip_image012.png
  5. 通过 web终端登录 Pod 查看挂载情况
    clip_image013.png
  6. 登录 ceph server 查看
    clip_image014.png

方法二:创建应用的时候同时创建卷


  1. 创建工作负载,配置数据卷选择添加新的持久化卷(声明)
    clip_image015.png
  2. 配置相应参数,比如添加卷声明名称,选择对应的存储类容量大小
    clip_image016.png
  3. 配置容器的挂载路径
    clip_image017.png
  4. 启动工作负载并登录容器查看卷挂载
    clip_image018.png
  5. 登录 ceph server 查看
    clip_image014.png

常见问题

image-20191105174349181.png


如果出现以上问题,请检查 worker 节点上是否有加载 RBD 模块。执行 lsmod | grep rbd 查看是否有信息返回,如果没有则执行 modprobe rbd 进行模块加载。

收起阅读 »

复用 Released 状态的 pv

文章来源: https://www.xtplayer.cn/kubernetes/reuse-released-pv/PV 回收策略当用户不再使用其存储卷时,他们可以从 API 中将 PVC 对象删除,从而允许 该资源被回收再利用。PersistentVolu...
继续阅读 »

文章来源: https://www.xtplayer.cn/kubernetes/reuse-released-pv/


PV 回收策略

当用户不再使用其存储卷时,他们可以从 API 中将 PVC 对象删除,从而允许 该资源被回收再利用。PersistentVolume 对象的回收策略告诉集群,当其被 从申领中释放时如何处理该数据卷。 目前,数据卷可以被 Retained(保留)、Recycled(回收,Recycle 已被废弃)或 Deleted(删除)。

保留(Retain)

回收策略 Retain 使得用户可以手动回收资源。当 PersistentVolumeClaim 对象 被删除时,PersistentVolume 卷仍然存在,对应的数据卷被视为” 已释放(released)”。 由于卷上仍然存在这前一申领人的数据,该卷还不能用于其他申领。 管理员可以通过下面的步骤来手动回收该卷:

  1. 删除 PersistentVolume 对象。与之相关的、位于外部基础设施中的存储资产 (例如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷)在 PV 删除之后仍然存在。
  2. 根据情况,手动清除所关联的存储资产上的数据。
  3. 手动删除所关联的存储资产;如果你希望重用该存储资产,可以基于存储资产的 定义创建新的 PersistentVolume 卷对象。

删除(Delete)

对于支持 Delete 回收策略的卷插件,删除动作会将 PersistentVolume 对象从 kubernetes 中移除,同时也会从外部基础设施(如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷)中移除所关联的存储资产。 动态供应的卷会继承其 StorageClass 中设置的回收策略,该策略默认 为 Delete。 管理员需要根据用户的期望来配置 StorageClass;否则 PV 卷被创建之后必须要被 编辑或者修补。参阅更改 PV 卷的回收策略.

参考:https://kubernetes.io/zh/docs/concepts/storage/persistent-volumes/#reclaiming

准备测试 pv 和 pvc

  1. 点击 集群 | 存储 | 持久卷,点击右侧添加 pv:

    image-20201208191644698.png
  2. 进入任意项目,点击 PVC,然后点击右侧 添加 pvc

    image-20201208191446393.pngimage-20201208191718549.pngimage-20201208191812212.png

通过命令查看 pv 和 pvc yaml 配置

  • pv

    YAML
    hxl@rancher:~$ kubectl get pv test-path-pv -oyaml

    apiVersion: v1
    kind: PersistentVolume
    metadata:
    annotations:
    field.cattle.io/creatorId: user-wf5x7
    pv.kubernetes.io/bound-by-controller: “yes”
    creationTimestamp: “2020-12-08T11:17:06Z”
    finalizers:
    - kubernetes.io/pv-protection
    labels:
    cattle.io/creator: norman
    name: test-path-pv
    resourceVersion: “24187470”
    selfLink: /api/v1/persistentvolumes/test-path-pv
    uid: 99f719ba-3314-48f3-9473-11e0b19a8806
    spec:
    accessModes:
    - ReadWriteOnce
    capacity:
    storage: 10Gi
    claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: test-path-pvc
    namespace: default
    resourceVersion: “24187465”
    uid: 88a75ff5-232a-44d5-8bbd-933fb325b80f
    hostPath:
    path: /tmp/test-path-pv
    type: “”
    persistentVolumeReclaimPolicy: Retain
    volumeMode: Filesystem
    status:
    phase: Bound
  • pvc

    YAML
    hxl@rancher:~$ kubectl get pvc test-path-pvc -oyaml

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
    annotations:
    field.cattle.io/creatorId: user-wf5x7
    pv.kubernetes.io/bind-completed: “yes”
    creationTimestamp: “2020-12-08T11:17:57Z”
    finalizers:
    - kubernetes.io/pvc-protection
    labels:
    cattle.io/creator: norman
    name: test-path-pvc
    namespace: default
    resourceVersion: “24187481”
    selfLink: /api/v1/namespaces/default/persistentvolumeclaims/test-path-pvc
    uid: 88a75ff5-232a-44d5-8bbd-933fb325b80f
    spec:
    accessModes:
    - ReadWriteOnce
    resources:
    requests:
    storage: 10Gi
    storageClassName: “”
    volumeMode: Filesystem
    volumeName: test-path-pv
    status:
    accessModes:
    - ReadWriteOnce
    capacity:
    storage: 10Gi
    phase: Bound

在 pv 的 spec.claimRef 可以看到对应 pvc 的具体信息,重要的有 name、namespace、uid。

测试删除 pvc

image-20201208192929197.png

因为 pv 的 persistentVolumeReclaimPolicy 属性为 Retain,在删除 pvc 后 pv,会自动保留,所以 pv 状态变为 Released

image-20201208193132639.png

编辑 pv

为了 pv 可以重新被挂载,需要执行 kubectl edit pv test-path-pv 命令,清理 spec.claimRef 中的内容,以使 pv 成为可用状态。

image-20201208193355828.pngimage-20201208193605364.png

重新创建 pvc

进入任意项目,点击 PVC,然后点击右侧 添加 pvc

image-20201208193745013.pngimage-20201208193825152.png

收起阅读 »

rancher k8s 使用 iscsi 存储

完整文章: https://www.xtplayer.cn/rancher/rancher-k8s-use-iscsi-storage/iSCSI 命名约定iSCSI 使用一种特殊、唯一的名称来标识 iSCSI 节点(目标或启动器)。此名称类似于与光纤通道设备...
继续阅读 »

完整文章: 

https://www.xtplayer.cn/rancher/rancher-k8s-use-iscsi-storage/


iSCSI 命名约定

iSCSI 使用一种特殊、唯一的名称来标识 iSCSI 节点(目标或启动器)。此名称类似于与光纤通道设备相关联的全球名称 (WWN),可作为一种通用的节点识别方式使用。iSCSI 名称通过两种不同方式格式化。最常见的是 IQN 格式。有关 iSCSI 命名要求和字符串配置文件的更多详细信息,请参见 IETF 网站上的 RFC 3721 和 RFC 3722。

iSCSI 限定名 (IQN) 格式

IQN 格式采用 iqn.yyyy-mm.naming-authority:unique name 的形式,其中:

  • yyyy-mm 是命名机构成立的年份和月份。

  • naming-authority 通常是命名机构的 Internet 域名的反向语法。例如,iscsi.vmware.com 命名机构的 iSCSI 限定名形式可能是 iqn.1998-01.com.vmware.iscsi。此名称表示 vmware.com 域名于 1998 年 1 月注册,iscsi 是一个由 vmware.com 维护的子域。

  • unique name 是希望使用的任何名称,如主机的名称。命名机构必须确保在冒号后面分配的任何名称都是唯一的,

    例如:

BASH
iqn.1998-01.com.vmware.iscsi:name1

iqn.1998-01.com.vmware.iscsi:name2

iqn.1998-01.com.vmware.iscsi:name999

企业唯一标识符 (EUI) 格式

EUI 格式采用 eui.16 hex digits 的形式。例如: eui.0123456789ABCDEF。

16 位十六进制数字是 IEEE EUI(扩展唯一标识符)格式的 64 位数的文本表示形式。前 24 位是 IEEE 向特定公司注册的公司 ID。后 40 位由持有该公司 ID 的实体分配,并且必须是唯一的。

更新 Kubernetes 集群 (可选)

Rancher 安装的 Kubernetes 集群,利用 iSCSI 启动器工具在 iSCSI 卷上存储数据,该工具嵌入在 kubelet 的 rancher/hyperkubeDocker 镜像中。在某些情况下,安装在 kubelet 容器中的启动器和 iscsi 服务器版本可能不匹配,从而导致连接失败。

如果遇到此问题,可以将集群中每个节点上安装启动器工具,然后将启动器工具映射到 kubelet 容器来解决版本问题。

平台包裹名字安装命令
Ubuntu/Debianopen-iscsisudo apt install open-iscsi
RHELiscsi-initiator-utilsyum install iscsi-initiator-utils -y

在节点上安装启动器工具后,编辑集群 YAML,编辑 kubelet 配置挂载主机 SCSI 二进制文件和配置目录,如下面的示例所示。

在更新 Kubernetes YAML 之前,请确保在集群节点上安装了 open-iscsi(deb)或 iscsi-initiator-utils(yum)软件包。如果在 Kubernetes YAML 中创建绑定挂载 之前 未安装此软件包,Docker 将自动在每个节点上创建目录和文件。

YAML
services:
kubelet:
extra_binds:
- "/etc/iscsi:/etc/iscsi"
- "/sbin/iscsiadm:/sbin/iscsiadm"
收起阅读 »

Rancher2.0UI无法删除工作负载

kubectl delete deployment --force xxxxxx
kubectl delete deployment --force xxxxxx

Rancher2.0通过nodeport映射端口后,只有POD所在主机能通过端口访问,其他主机无法访问

Rancher2.0通过nodeport映射端口后,只有POD所在主机能通过端口访问,其他主机无法访问   这个问题有可能是iptables把相应的转发包丢弃了   解决方法:sudo iptables -P FORWARD ACCEPT,打开全局的转发规则 ...
继续阅读 »
Rancher2.0通过nodeport映射端口后,只有POD所在主机能通过端口访问,其他主机无法访问
 
这个问题有可能是iptables把相应的转发包丢弃了
 
解决方法:sudo iptables -P FORWARD ACCEPT,打开全局的转发规则
  收起阅读 »

Docker deamon 配置参数

[code]{ "authorization-plugins": [], "data-root": "", "dns": [], "dns-opts": [], "dns-search": [], "exec-opts": [], "exec-r...
继续阅读 »
{
"authorization-plugins": [],
"data-root": "",
"dns": [],
"dns-opts": [],
"dns-search": [],
"exec-opts": [],
"exec-root": "",
"experimental": false,
"storage-driver": "",
"storage-opts": [],
"labels": [],
"live-restore": true,
"log-driver": "",
"log-opts": {},
"mtu": 0,
"pidfile": "",
"cluster-store": "",
"cluster-store-opts": {},
"cluster-advertise": "",
"max-concurrent-downloads": 3,
"max-concurrent-uploads": 5,
"default-shm-size": "64M",
"shutdown-timeout": 15,
"debug": true,
"hosts": [],
"log-level": "",
"tls": true,
"tlsverify": true,
"tlscacert": "",
"tlscert": "",
"tlskey": "",
"swarm-default-advertise-addr": "",
"api-cors-header": "",
"selinux-enabled": false,
"userns-remap": "",
"group": "",
"cgroup-parent": "",
"default-ulimits": {},
"init": false,
"init-path": "/usr/libexec/docker-init",
"ipv6": false,
"iptables": false,
"ip-forward": false,
"ip-masq": false,
"userland-proxy": false,
"userland-proxy-path": "/usr/libexec/docker-proxy",
"ip": "0.0.0.0",
"bridge": "",
"bip": "",
"fixed-cidr": "",
"fixed-cidr-v6": "",
"default-gateway": "",
"default-gateway-v6": "",
"icc": false,
"raw-logs": false,
"allow-nondistributable-artifacts": [],
"registry-mirrors": [],
"seccomp-profile": "",
"insecure-registries": [],
"no-new-privileges": false,
"default-runtime": "runc",
"oom-score-adjust": -500,
"node-generic-resources": ["NVIDIA-GPU=UUID1", "NVIDIA-GPU=UUID2"],
"runtimes": {
"cc-runtime": {
"path": "/usr/bin/cc-runtime"
},
"custom": {
"path": "/usr/local/bin/my-runc-replacement",
"runtimeArgs": [
"--debug"
]
}
}}
收起阅读 »

2.0常见的前端状态提示

[code]'activating':      'active':          'available':       'bound':           'backedup':        'created':         'creating'...
继续阅读 »
'activating':   
  'active':       
  'available':    
  'bound':        
  'backedup':     
  'created':      
  'creating':     
  'deactivating': 
  'degraded':     
  'disconnected': 
  'error':        
  'erroring':     
  'expired':      
  'healthy':       
  'inactive':     
  'initializing': 
  'migrating':    
  'paused':       
  'provisioning': 
  'pending':      
  'purged':       
  'purging':      
  'reconnecting': 
  'registering':  
  'released':     
  'reinitializing':
  'removed':      
  'removing':     
  'requested':    
  'restarting':   
  'restoring':    
  'running':      
  'starting':     
  'stopped':      
  'stopping':     
  'succeeded':    
  'terminated':   
  'unavailable':  
  'unhealthy':    
  'unknown':      
  'updating':     
  'waiting':
收起阅读 »

Rancher1.6常见故障排查与修复方法

一、服务/容器1、为什么我只能编辑容器的名称? Docker容器在创建之后就不可更改了。唯一可更改的内容是我们要存储的不属于Docker容器本身的那一部分数据。 无论是停止、启动或是重新启动,它始终在使用相同的容器。如需改变任何内容都需要删除或重新创建一个容器...
继续阅读 »
一、服务/容器1、为什么我只能编辑容器的名称?
Docker容器在创建之后就不可更改了。唯一可更改的内容是我们要存储的不属于Docker容器本身的那一部分数据。 无论是停止、启动或是重新启动,它始终在使用相同的容器。如需改变任何内容都需要删除或重新创建一个容器。
你可以克隆,即选择已存在的容器,并基于已有容器的配置提前在添加服务界面中填入所有要设置的内容,如果你忘记填入某项内容,可以通过克隆来改变它之后删除旧的容器。2、service-link的容器/服务在Rancher中是如何工作的?
在Docker中,关联容器(在 
docker run
中使用
--link
)的ID和IP地址会出现在容器的
/etc/hosts
中。在Rancher中,我们不需要更改容器的
/etc/hosts
文件,而是通过运行一个内部DNS服务器来关联容器,DNS服务器会返回给我们正确的IP。3、不能通过Rancher的界面打开命令行或查看日志,如何去访问容器的命令行和日志?
Agent主机有可能会暴露在公网上,Agent上接受到的访问容器命令行或者日志的请求是不可信的。Rancher Server中发出的请求包括一个JWT(JSON Web Token),JWT是由服务器签名并且可由Agent校验的,Agent可以判断出请求是否来自服务器,JWT中包括了有效期限,有效期为5分钟。这个有效期可以防止它被长时间使用。如果JWT被拦截而且没有用SSL时,这一点尤为重要。
如果你运行
docker logs -f (rancher-agent名称或ID)
。日志会显示令牌过期的信息,随后检查Rancher Server主机和Rancher Agent主机的时钟是否同步。4、在哪里可以看到我的服务日志?
在服务的详细页中,我们提供了一个服务日志的页签日志。在日志页签中,列出了和服务相关的所有事件,包括时间戳和事件相关描述,这些日志将会保留24小时。5、RANCHER SERVER 点击WEB shell屏幕白屏
如果RANCHER SERVER 运行在V1.6.2版本,点击WEB shell出现白屏,这是UI上的一个BUG,请选择升级server服务。二、跨主机通信
如果容器运行在不同主机上,不能够ping通彼此, 可能是由一些常见的问题引起的.1、如何检查跨主机通信是否正常?
在应用->基础设施中,检查 
healthcheck
 应用的状态。如果是active跨主机通信就是正常的。
手动测试,你可以进入任何一个容器中,去ping另一个容器的内部IP。在主机页面中可能会隐藏掉基础设施的容器,如需查看点击“显示系统容器”的复选框。2、UI中显示的主机IP是否正确?
有时,Docker网桥的IP地址会被错误的作为了主机IP,而并没有正确的选择真实的主机IP。这个错误的IP通常是
172.17.42.1
或以
172.17.x.x
开头的IP。如果是这种情况,在使用
docker run
命令添加主机时,请用真实主机的IP地址来配置
CATTLE_AGENT_IP
环境变量。
 sudo docker run -d -e CATTLE_AGENT_IP= --privileged \
 -v /var/run/docker.sock:/var/run/docker.sock \
 rancher/agent:v0.8.2 http://SERVER_IP:8080/v1/scripts/xxxx
3、Rancher的默认子网(
10.42.0.0/16
)在我的网络环境中已经被使用或禁止使用,我应该怎么去更改这个子网?
Rancher Overlay网络默认使用的子网是
10.42.0.0/16
。如果这个子网已经被使用,你将需要更改Rancher网络中使用的默认子网。你要确保基础设施服务里的Network组件中使用着合适的子网。这个子网定义在该服务的
rancher-compose.yml
文件中的
default_network
里。
要更改Rancher的IPsec或VXLAN网络驱动,你将需要在环境模版中修改网络基础设施服务的配置。创建新环境模板或编辑现有环境模板时,可以通过单击编辑来配置网络基础结构服务的配置。在编辑页面中,选择配置选项 > 子网输入不同子网,点击配置。在任何新环境中将使用环境模板更新后的子网,编辑已经有的环境模板不会更改现在已有环境的子网。
这个实例是通过升级网络驱动的
rancher-compose.yml
文件去改变子网为
10.32.0.0/16
.
ipsec:
  network_driver:
    name: Rancher IPsec
    default_network:
      name: ipsec
      host_ports: true
      subnets:
      # After the configuration option is updated, the default subnet address is updated
      - network_address: 10.32.0.0/16
      dns:
      - 169.254.169.250
      dns_search:
      - rancher.internal
    cni_config:
      '10-rancher.conf':
        name: rancher-cni-network
        type: rancher-bridge
        bridge: docker0
        # After the configuration option is updated, the default subnet address is updated
        bridgeSubnet: 10.32.0.0/16
        logToFile: /var/log/rancher-cni.log
        isDebugLevel: false
        isDefaultGateway: true
        hostNat: true
        hairpinMode: true
        mtu: 1500
        linkMTUOverhead: 98
        ipam:
          type: rancher-cni-ipam
          logToFile: /var/log/rancher-cni.log
          isDebugLevel: false
          routes:
          - dst: 169.254.169.250/32


注意: 随着Rancher通过升级基础服务来更新子网,以前通过API更新子网的方法将不再适用。


4、VXLAN 网络模式下,跨主机容器无法通信
Vxlan 通过4789端口实现通信,检查防火墙有没有开放此端口;
执行 iptables -t filter -L -n 参看IPtable表, 查看chain FORWARD 是不是被丢弃,如果是,执行sudo iptables -P FORWARD ACCEPT三、DNS1、如何查看我的DNS是否配置正确?
如果你想查看Rancher DNS配置,点击应用 > 基础服务。点击
network-services
应用,选择
metadata
,在
metadata
中,找到名为
network-services-metadata-dns-X
的容器,通过UI点击执行命令行后,可以进入该容器的命令行,然后执行如下命令。
cat /etc/rancher-dns/answers.json
八、在Ubuntu上运行容器时彼此间不能正常通信。
如果你的系统开启了
UFW
,请关闭
UFW
或更改
/etc/default/ufw
中的策略为:
DEFAULT_FORWARD_POLICY="ACCEPT"
四、负载均衡1、为什么我的负载均衡一直是
Initializing
状态?
负载均衡器自动对其启用健康检查。 如果负载均衡器处于初始化状态,则很可能主机之间无法进行跨主机通信。2、我如何查看负载均衡的配置?
如果要查看负载均衡器的配置,你需要用进入负载均衡器容器内部查找配置文件,你可以在页面选择负载均衡容器的执行命令行
cat /etc/haproxy/haproxy.cfg

该文件将提供负载均衡器的所有配置详细信息。3、我在哪能找到HAproxy的日志?
HAProxy的日志可以在负载均衡器容器内找到。 负载均衡器容器的
docker logs
只提供与负载均衡器相关的服务的详细信息,但不提供实际的HAProxy日志记录。
cat /var/log/haproxy
4、如何自定义负载均衡的配置
如图,在自定义配置中,按照global、defaults、frontend、backend的格式配置,五、健康检查1、为什么健康检查服务一直显示黄色初始化状态?
healthcheck不仅为其他服务提供健康检查,对系统组件(比如调度服务)也提供健康检查服务,healthcheck也对自己进行健康检查。多个healthcheck组件时,它们会相互交叉检查,只有健康检查通过后,容器状态才会变成绿色。 而healthcheck一直显示黄色初始化状态,说明一直没有通过健康检查。健康检查都是通过网络访问的,所以一定是网络通信异常导致。六、调度
为什么节点关机后,应用没有自动调度到其他节点上? Rancher上应用的调度,需要配合健康检查功能。当健康检查检查到应用不健康才会重新调度,如果没有配置健康检查, 即使关机,cattle也不会对应用做调度处理。七、CentOS1、为什么容器无法连接到网络?
如果你在主机上运行一个容器(如:
docker run -it ubuntu
)该容器不能与互联网或其他主机通信,那可能是遇到了网络问题。 Centos默认设置
/proc/sys/net/ipv4/ip_forward
0
,这从底层阻断了Docker所有网络。
解决办法:
vi /usr/lib/sysctl.d/00-system.conf

添加如下代码:
net.ipv4.ip_forward=1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 1

重启network服务
systemctl restart network

查看是否修改成功
sysctl net.ipv4.ip_forward

如果返回为
net.ipv4.ip_forward = 1
则表示成功了八、京东云1、京东云运行rancher server 出现以下问题

解决办法:
sudo sysctl -w net.ipv4.tcp_mtu_probing=1
九、阿里云主机运行Rancher-NFS驱动报如下错误
 

解决办法:注释掉 /etc/resolv.conf  中option 有关的行 收起阅读 »

Rancher Agent 1.6

1、Rancher Agent无法启动的原因是什么?1.1、添加 [code]--NAME RANCHER-AGENT[/code] (老版本) 如果你从UI中编辑[code]docker run .... rancher/agent...[/code]命令并...
继续阅读 »
1、Rancher Agent无法启动的原因是什么?1.1、添加 
--NAME RANCHER-AGENT
 (老版本)
如果你从UI中编辑
docker run .... rancher/agent...
命令并添加
--name rancher-agent
选项,那么Rancher Agent将启动失败。Rancher Agent在初始运行时会启动3个不同容器,一个是运行状态的,另外两个是停止状态的。Rancher Agent要成功连接到Rancher Server必须要有两个名字分别为
rancher-agent
rancher-agent-state
的容器,第三个容器是docker自动分配的名称,这个容器会被移除。1.2、使用一个克隆的虚拟机
如果你使用了克隆其他Agent主机的虚拟机并尝试注册它,它将不能工作。在rancher-agent容器的日志中会产生
ERROR: Please re-register this agent.
字样的日志。Rancher主机的唯一ID保存在
/var/lib/rancher/state
,因为新添加和虚拟机和被克隆的主机有相同的唯一ID,所以导致无法注册成功。
解决方法是在克隆的VM上运行以下命令:
rm -rf /var/lib/rancher/state; docker rm -fv rancher-agent; docker rm -fv rancher-agent-state

完成后可重新注册。2、我在哪里可以找到Rancher agent容器的详细日志?
从v1.6.0起,在rancher-agent容器上运行
docker logs
将提供agent相关的所有日志。3、主机是如何自动探测IP的?我该怎么去修改主机IP?如果主机IP改变了(因为重启),我该怎么办?
当Agent连接Rancher Server时,它会自动检测Agent的IP。有时,自动探测的IP不是你想要使用的IP,或者选择了docker网桥的IP,如. 
172.17.x.x
。 或者,你有一个已经注册的主机,当主机重启后获得了一个新的IP, 这个IP将会和Rancher UI中的主机IP不匹配。 你可以重新配置“CATTLE_AGENT_IP”设置,并将主机IP设置为你想要的。 当主机IP地址不正确时,容器将无法访问管理网络。要使主机和所有容器进入管理网络,只需编辑添加自定义主机的命令行,将新的IP指定为环境变量“CATTLE_AGENT_IP”。 在主机上运行编辑后的命令。 不要停止或删除主机上的现有的Rancher Agent容器!
sudo docker run -d -e CATTLE_AGENT_IP= --privileged \-v /var/run/docker.sock:/var/run/docker.sock \rancher/agent:v0.8.2 http://SERVER_IP:8080/v1/scripts/xxxx
4、错误提示如下:INFO: Attempting to connect to: http://192.168.xx.xx:8080/v1 ERROR: http://192.168.xx.xx:8080/v1 is not accessible (Failed to connect to 192.168.xx.xx port 8080: No route to host)
这个问题主要有以下几种情况:
1.RANCHER SERVER服务器防火墙没有开通8080端口;
2.云平台安全组没有放行8080端口;
3.Agent 服务器没有开启IP转发规则 [为什么我的容器无法连接到网络?]:{site.baseurl}}/rancher/faqs/ troubleshooting/1为什么我的容器无法连接到网络;
=1为开启,=0为关闭
/etc/sysctl.conf
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

4.主机hosts(
/etc/hosts
)文件没有配置;5、rancher下创建的服务容器,docker inspect 查看到Entrypoint和CMD后面有/.r/r字符,这个起什么作用?
./r 是基于weave wait编译出来的。 CNI网络下会添加/.r/r 这个参数,目的是:当容器启动时,其实网络设备还没设置好,这时候需要container 等待,不能启动真实业务,否则会失败。6、Host not registered yet. Sleeping 1 second and trying again.” Attempt=0 reportedUuid=752031dd-8c7e-4666-5f93-020d7f4da5d3
检查主机名和hosts配置, hosts中需要配置:
127.0.0.1 localhost
hostip hostname7、Rancher cattle , 为什么添加第二台主机后会把第一台主机替换掉?
在/var/lib/rancher/ 目录下保存了每个节点的注册配置信息。如果是克隆的主机,在/var/lib/rancher/ 目录有相同的内容,当新加主机的时候会识别为重新添加某台主机,这样之前添加的主机就会被替换掉。
解决办法:新加主机时,删除/var/lib/rancher/ 目录。 收起阅读 »

Rancher Server 1.6 常见问题

1、Docker 运行Rancher server 容器应该注意什么? 需要注意运行rancher server 容器时,不要使用host模式。程序中有些地方定义的是localhost或者127.0.0.1,如果容器网络设置为host,将会去访问宿主机资源,因...
继续阅读 »
1、Docker 运行Rancher server 容器应该注意什么?
需要注意运行rancher server 容器时,不要使用host模式。程序中有些地方定义的是localhost或者127.0.0.1,如果容器网络设置为host,将会去访问宿主机资源,因为宿主机并没有相应资源,rancher server 容器启动就出错。
PS:docker命令中,如果使用了 --network host参数,那后面再使用-p 8080:8080 就不会生效。
docker run -d -p 8080:8080 rancher/server:stable

此命令仅适用于单机测试环境,如果要生产使用Rancher server,请使用外置数据库(mysql)或者通过
-v /xxx/mysql/:/var/lib/mysql -v /xxx/log/:/var/log/mysql -v /xxx/cattle/:/var/lib/cattle

把数据挂载到宿主机上。如果用外置数据库,需提前对数据库做性能优化,以保证Rancher 运行的最佳性能。2、如何导出Rancher Server容器的内部数据库?
你可以通过简单的Docker命令从Rancher Server容器导出数据库。
docker exec  mysqldump cattle > dump.sql
3、我正在运行的Rancher是什么版本的?
Rancher的版本位于UI的页脚的左侧。 如果你点击版本号,将可以查看其他组件的详细版本。4、如果我没有在Rancher UI中删除主机而是直接删除会发生什么?
如果你的主机直接被删除,Rancher Server会一直显示该主机。主机会处于
Reconnecting
状态,然后转到
Disconnected
状态。 你也可以通过添加主机再次把此节点添加到RANCHER 集群,如果不在使用此节点,可以在UI中删除。
如果你有添加了健康检查功能的服务自动调度到状态
Disconnected
主机上,CATTLE会将这些服务重新调度到其他主机上。
PS:如果使用了标签调度,如果你有多台主机就有相同的调度标签,那么服务会调度到其他具有调度标签的节点上;如果选择了指定运行到某台主机上,那主机删除后你的应用将无法在其他主机上自动运行。
5、我如何在代理服务器后配置主机?
要在代理服务器后配置主机,你需要配置Docker的守护进程。详细说明参考在代理服务器后添加自定义主机。6、为什么同一主机在UI中多次出现?
宿主机上
var/lib/rancher/state
这个文件夹,这是Rancher用来存储用于标识主机的必要信息. .registration_token中保存了主机的验证信息,如果里面的信息发生变化,RANCHER会认为这是一台新主机, 在你执行添加主机后,UI上将会出现另外一台相同的主机,第一台主机接着处于失联状态。7、在哪能找到 Rancher Server 容器的详细日志?
运行
docker logs
可以查看在Rancher Server容器的基本日志。要获取更详细的日志,你可以进入到Rancher Server容器内部并查看日志文件。
进入 Rancher Server 容器内部
docker exec -it  bash

跳转到 Cattle 日志所在的目录下cd /var/lib/cattle/logs/
cat cattle-debug.log

在这个目录里面会出现
cattle-debug.log
cattle-error.log
。 如果你长时间使用此Rancher Server,你会发现我们每天都会创建一个新的日志文件。8、将Rancher Server的日志复制到主机上。
以下是将Rancher Server日志从容器复制到主机的命令。
docker cp :/var/lib/cattle/logs /local/path
9、如果Rancher Server的IP改变了会怎么样?
如果更改了Rancher Server的IP地址,你需要用新的IP重新注册主机。
在Rancher中,点击系统管理->系统设置更新 Rancher Server的主机注册地址。注意必须包括Rancher Server暴露的端口号。默认情况下我们建议按照安装手册中使用8080端口。
主机注册更新后,进入基础架构->添加主机->自定义。 添加主机的
docker run
命令将会更新。 使用更新的命令,在Rancher Server的所有环境中的所有主机上运行该命令。10、Rancher Server运行变得很慢,怎么去优化它?
很可能有一些任务由于某些原因而处于僵死状态,如果你能够用界面查看系统管理 -> 系统进程,你将可以看到
Running
中的内容,如果这些任务长时间运行(并且失败),则Rancher会最终使用太多的内存来跟踪任务。这使得Rancher Server处于了内存不足的状态。
为了使服务变为可响应状态,你需要添加更多内存。通常4GB的内存就够了。
你需要再次运行Rancher Server命令并且添加一个额外的选项
-e JAVA_OPTS="-Xmx4096m"
docker run -d -p 8080:8080 --restart=unless-stopped -e JAVA_OPTS="-Xmx4096m" rancher/server

根据MySQL数据库的设置方式的不同,你可能需要进行升级才能添加该选项。
如果是由于缺少内存而无法看到系统管理 -> 系统进程的话,那么在重启Rancher Server之后,已经有了更多的内存。你现在应该可以看到这个页面了,并可以开始对运行时间最长的进程进行故障分析。11、Rancher Server数据库数据增长太快.
Rancher Server会自动清理几个数据库表,以防止数据库增长太快。如果对你来说这些表没有被及时清理,请使用API来更新清理数据的时间间隔。
在默认情况下,产生在2周以前的
container_event
service_event
表中的数据则数据会被删除。在API中的设置是以秒为单位的(
1209600
)。API中的设置为
events.purge.after.seconds
.
默认情况下,
process_instance
表在1天前产生的数据将会被删除,在API中的设置是以秒为单位的(
86400
)。API中的设置为
process_instance.purge.after.seconds
.
为了更新API中的设置,你可以跳转到
http://:8080/v1/settings
页面, 搜索要更新的设置,点击
links -> self
跳转到你点击的链接去设置,点击侧面的“编辑”更改’值’。 请记住,值是以秒为单位。12、为什么Rancher Server升级失败导致数据库被锁定?
如果你刚开始运行Rancher并发现它被永久冻结,可能是liquibase数据库上锁了。在启动时,liquibase执行模式迁移。它的竞争条件可能会留下一个锁定条目,这将阻止后续的流程。
如果你刚刚升级,在Rancher Server日志中,MySQL数据库可能存在尚未释放的日志锁定。
....liquibase.exception.LockException: Could not acquire change log lock. Currently locked by 
释放数据库锁


注意: 请不要释放数据库锁,除非有相关日志锁的异常。如果是由于数据迁移导致升级时间过长,在这种情况下释放数据库锁,可能会使你遇到其他迁移问题。


如果你已根据升级文档创建了Rancher Server的数据容器,你需要
exec
rancher-data
容器中升级
DATABASECHANGELOGLOCK
表并移除锁,如果你没有创建数据容器,你用
exec
到包含有你数据库的容器中。
sudo docker exec -it  mysql

一旦进入到 Mysql 数据库, 你就要访问
cattle
数据库。
mysql> use cattle;

检查表中是否有锁mysql> select * from DATABASECHANGELOGLOCK;

更新移除容器的锁mysql> update DATABASECHANGELOGLOCK set LOCKED="", LOCKGRANTED=null, LOCKEDBY=null where ID=1;

检查锁已被删除mysql> select * from DATABASECHANGELOGLOCK;
+----+--------+-------------+----------+
| ID | LOCKED | LOCKGRANTED | LOCKEDBY |
+----+--------+-------------+----------+
|  1 |        | NULL        | NULL     |
+----+--------+-------------+----------+
1 row in set (0.00 sec)
13、管理员密码忘记了,我该如何重置管理员密码?
如果你的身份认证出现问题(例如管理员密码忘记),则可能无法访问Rancher。 要重新获得对Rancher的访问权限,你需要在数据库中关闭访问控制。 为此,你需要访问运行Rancher Server的主机。
ps:假设在重置访问控制之前有创建过其他用户,那么在认证方式没有变化的情况下,重置访问控制除了超级管理员(第一个被创建的管理员,ID为1a1),其他用户账号信息不会受影响。
  • 假设数据库为rancher内置数据库
docker exec -it  mysql

注意: 这个 

是具有Rancher数据库的容器。 如果你升级并创建了一个Rancher数据容器,则需要使用Rancher数据容器的ID而不是Rancher Server容器,rancher内置数据库默认密码为空。

  • 选择Cattle数据库。
mysql> use cattle;
  • 查看
    setting
    表。
mysql> select * from setting;
  • 更改
    api.security.enabled
    false
    ,并清除
    api.auth.provider.configured
    的值。
# 关闭访问控制mysql> update setting set value="false" where name="api.security.enabled";# 清除认证方式mysql> update setting set value="" where name="api.auth.provider.configured";
  • 确认更改在
    setting
    表中是否生效。
mysql> select * from setting;
  • 可能需要约1分钟才能在用户界面中关闭身份认证,然后你可以通过刷新网页来登陆没有访问控制的Rancher Server

关闭访问控制后,任何人都可以使用UI/API访问Rancher Server。

  • 刷新页面,在系统管理访问控制 重新开启访问控制。重新开启访问控制填写的管理员用户名将会替换原有的超级管理员用户名(ID为1a1 )。

14、Rancher Compose Executor和Go-Machine-Service不断重启.
在高可用集群中,如果你正在使用代理服务器后,如果rancher-compose-executor和go-machine-service不断重启,请确保你的代理使用正确的协议。15、我怎么样在代理服务器后运行Rancher Server?
请参照在HTTP代理后方启动Rancher Server.16、为什么在日志中看到Go-Machine-Service在不断重新启动? 我该怎么办?
Go-machine-service是一种通过websocket连接到Rancher API服务器的微服务。如果无法连接,则会重新启动并再次尝试。如果你运行的是单节点的Rancher Server,它将使用你为主机注册地址来连接到Rancher API服务。 检查从Rancher Sever容器内部是否可以访问主机注册地址。
docker exec -it  bash
在 Rancher-Server 容器内
curl -i /v1

你应该得到一个json响应。 如果认证开启,响应代码应为401。如果认证未打开,则响应代码应为200。 验证Rancher API Server 能够使用这些变量,通过登录go-machine-service容器并使用你提供给容器的参数进行
curl
命令来验证连接:
docker exec -it  bash
在go-machine-service 容器内
curl -i -u ':

你应该得到一个json响应和200个响应代码。 如果curl命令失败,那么在
go-machine-service
和Rancher API server之间存在连接问题。 如果curl命令没有失败,则问题可能是因为go-machine-service尝试建立websocket连接而不是普通的http连接。 如果在go-machine-service和Rancher API服务器之间有代理或负载平衡,请验证代理是否支持websocket连接。17、rancher catalog 多久同步一次
http://X.X.X.X/v1/settings/catalog.refresh.interval.seconds 默认300秒 可以修改 点setting会立即更新18、Rancher server cattle-debug.log 文件占满磁盘的问题
这个问题主要在Rancher server 1.6.11 之前(1.6.11 已经解决)
目前是按天来创建日志文件, 如果日志文件太多会进行日志分段,每一段默认100M, 默认情况下,系统保留5个分段。 通过打开http://rancher_url:8080/v2-beta/settings ,网页搜索 logback 可以看到以下内容,
{"id": "logback.max.file.size","type": "activeSetting","links": {"self": "…/v2-beta/settings/logback.max.file.size"},"actions": { },"baseType": "setting","name": "logback.max.file.size","activeValue": "100MB","inDb": false,"source": "Code Packaged Defaults","value": "100MB"},{"id": "logback.max.history","type": "activeSetting","links": {"self": "…/v2-beta/settings/logback.max.history"},"actions": { },"baseType": "setting","name": "logback.max.history","activeValue": "5","inDb": false,"source": "Code Packaged Defaults","value": "5"},

点击self 后的相应类型,比如”self”: “…/v2-beta/settings/logback.max.history” 可以做相应参数调整。
相应issue:https://github.com/rancher/rancher/issues/988719、Rancher server 如何免密更新Catalog
在配置 私有仓库地址的时候,添加用户名和密码
https://{username}:{password}@github.com/{repo}
20、修改server 日志等级
默认情况下,server日志记录等级为INFO,可以按照以下方法修改:
通过打开 http://rancher_url:8080/v2-beta/settings/auth.service.log.level ,

点击编辑 修改


点击show Request,再点击send Request.

收起阅读 »

Rancher-Ceph卷驱动部署

操作步骤Ceph 服务端安装如果没有Ceph 服务器,可以通过容器运行一个Ceph 服务器 DEMO环境:docker run -d –net=host -v /etc/ceph:/etc/ceph -e MON_IP=172.18.0.11 -e CEPH_...
继续阅读 »

操作步骤Ceph 服务端安装
如果没有Ceph 服务器,可以通过容器运行一个Ceph 服务器 DEMO环境:
docker run -d –net=host -v /etc/ceph:/etc/ceph -e MON_IP=172.18.0.11 -e CEPH_PUBLIC_NETWORK=172.18.0.0/24 ceph/demtag-build-master-jewel-ubuntu-16.04
IP地址根据实际情况修改。


把Ceph 服务容器所在宿主机/etc/ceph路径下所有文件复制到Rancher 环境下所有节点的相同路径下。Rancher下Ceph应用安装应用商店添加进入 系统管理系统设置 添加一个名为Ceph的自定义商店


名称:Ceph
地址:https://github.com/niusmallnan/rancher-rbd-catalog.git
分支:masterCeph应用安装
进入应用商店,搜索RBD进行安装。

安装完成后:

再进 系统架构存储 查看:

安装测试应用应用安装

新建一个名为myapp的空应用栈并添加服务:


红色线框为配置重点:
使用驱动卷插件与使用本地卷驱动有所区别, 使用本地卷驱动添加卷 时应该写 /AA/BB:/CC/DD,前后都要为路径; 使用驱动卷插件 时应该写为 A:/BB/CC 。 这个的A为一个卷名,不能是路径。因为我们是Ceph存储,这里需要填卷驱动为:rancher-rbd 。

部署好之后如图:

查看 基础架构存储

数据存储测试

在容器中向/root 目录下新建一个文件:

现在这个容器位于node2上, 接着把这个服务容器删除,删除后myapp应用栈为空:

接着,在空的应用栈中添加一个服务,并手动调度容器运行到其他节点上。

PS:新建的服务,参数中的卷名与卷映射路径必须相同,卷驱动也要相同。

服务运行成功,运行在node1上

查看 基础架构存储

进入容器的/root目录查看创建的文件

文件依然存在,说明文件不是存在本地,证明Ceph存储对接成功。

收起阅读 »

Rancher日志收集

引言 文档参考[url]http://www.cnrancher.com/rancher-logging/[/url] 。 一个完整的容器平台,容器日志收集也是很重要的一环。尤其在微服务架构大行其道状况下,程序的访问监控、健康状态检查很多都依赖日志信息的收集,...
继续阅读 »
引言
文档参考http://www.cnrancher.com/rancher-logging/ 。
一个完整的容器平台,容器日志收集也是很重要的一环。尤其在微服务架构大行其道状况下,程序的访问监控、健康状态检查很多都依赖日志信息的收集,由于Docker的存在,让容器平台中的日志收集和传统方式很多不一样,日志的输出和收集与以前也大有不同。本文就此探讨一下,Rancher平台内如何做容器日志收集。现状
纵览当前容器日志收集的各种解决方案,无非就是两种方式:一、直接采集Docker标准输出,通过Docker的日志驱动(log driver)可以发送到相应的收集程序中;二、非标准输出,延续传统的日志写入方式,容器内的服务将日志直接写到Log文件中,通过Docker volume映射形式,将日志文件映射到Host上,日志采集程序直接收集映射出来的Log文件。三、通Journald 收集二进制日志数据。
PS:
标准输出:即通过docker logs查看到的日志信息。Ubuntu OS下,这些信息默认保存在/var/lib/docker/containers路径下以容器ID为名的文件夹下并以容器ID为前缀的 -json.log 文件中。
非标准输出:根据Docker容器的特性,容器启动后必须有一个服务保持前台运行。如果一个容器要运行多个服务,那么按照启动顺序,前面的服务就必须得后台运行。 所以,默认情况下这些后台运行的服务产生的日志将无法以标准输出获取,产生的日志默认会存放于/var/log 目录下。
第一种方式足够简单,直接配置相关的日志驱动(Log driver)就可以,但是这种方式也有些劣势:
  1. 当主机的容器密度比较高的时候,对Docker Engine的压力比较大,毕竟容器标准输出都要通过Docker Engine来处理。
  2. 尽管原则上,我们希望遵循一容器部署一个服务的原则,但是有时候特殊情况不可避免容器内有多个业务服务,这时候很难做到所有服务都标准输出日志,这就需要用到传统的方式收集log日志。
  3. 虽然我们可以选择很多种Log Driver,但是有些Log Driver会破坏Docker原生的体验,比如,日志输出到其他日志服务器后,docker logs将无法看到容器日志。

基于以上考虑,一个完整的日志收集方案必须要同时满足标准输出收集和日志卷(非标准输出)收集或者通过journald 收集二进制日志数据 。当然完整的日志体系中,并不仅仅是采集,还需要有日志存储和UI展现。日志存储有很多种开源的实现,这个一般用户都会有自己钟情的选择。而UI展现更是各家有各家的需求,很难形成比较好的标准,一般都是通过定制化方式解决。所以此文主要展现的方案是日志采集方案,当然在存储和UI展现上会对接开源实现,没有特殊需求的情况下,也可以拥有一个完整的体验。

Rancher下的解决方案(json-file驱动)方案介绍
如上面图中所示,日志存储和UI展现可以直接使用ElasticSearch & Kibana。日志采集方面如之前所分析,需要对接两种采集模式(标准输出日志和非标准输出),本方案中,日志采集这部分采用Fluentd & Logging Helper的组合。Fluentd是很通用的日志采集程序,拥有优异的性能,相对Logstash来说同等压力下,其内存消耗要少很多。
为了要保证Dokcer和Rancher体验的完整性,之所以Docker Log Driver选择Json-file或者Journald,其原因:一、json-file和journald相对来说比较常用;二、这两种驱动下,docker logs依然可以有内容输出,保证了体验的完整性。实现流程
方案实现流程:Fluentd对接Json-file或者Journald驱动,获取标准输出日志数据或者二进制日志数据; Logging Helper可以理解为Fluentd的助手,它可以识别容器日志卷(非标准输出)映射的路径,并通知Fluentd进行采集。 Fluentd收集数据后,接着数据被传递并存储到ES,最后Kibana将ES中的数据直接展示出来。
下面开始说明,整个方案的部署过程。先用一张图来描述整体的部署结构,如下:
方案部署ElasticSearch & Kibana部署
通过web登录Rancher,进入应用商店,搜索ElasticSearch,推荐安装2.x版本。

点击查看详情, 进去后修改一下最后的Public port,默认为80端口, 改为其他端口避免端口冲突。
接着再进入应用商店搜索Kibana.

配置选项中,需选择Elasticsearch-clients

最后的Public port 根据实际情况进行修改,避免冲突。

服务正常启动后,可以通过这个端口访问Kibana web 页面。
Rancher logging服务部署目前Rancher logging不在官方仓库中,所以需要使用Rancher logging 需要添加自定义商店地址。 点击小图管理系统设置 进入, 点击添加应用商店,
名称:rancher -logging
地址: https://github.com/niusmallnan/rancher-logging-catalog.git
分支:master
最后点击保存,并返回应用商店。在应用商店中输入log进行搜索:

点击查看详情进去,进入配置页面:在本示例中,除了Elasticsearch source 如图配置外,其他保持默认:

以上部署完成之后,部署一些应用并产生一些访问日志,就可以在Kibana的界面中看到:

若要使用日志卷方式,则需要在Service启动的时候配置Volume,Volume name需要匹配之前设定的Volume Pattern:
收起阅读 »

webhook实现服务自动升级

https://www.xtplayer.cn/rancher/rancher16-webhook-auto-update/概述前面的文章我们有讲述了如何通过 Rancher-webhook 实现 Service/Host 的弹性伸缩。今天我们再来演示一下如何...
继续阅读 »

https://www.xtplayer.cn/rancher/rancher16-webhook-auto-update/

概述

前面的文章我们有讲述了如何通过 Rancher-webhook 实现 Service/Host 的弹性伸缩。今天我们再来演示一下如何通过 Rancher-webhook 对接三方的 CI 系统,实现微服务镜像的自动构建与服务的自动升级。

PS: CI 即持续集成,包括但不限于自动编译、发布和测试、自动构建,我们这里说的 CI 系统仅限于自动构建这一步。 前面已经对 webhook 做了介绍,这里不再讲解。
本文主要基于阿里云的容器镜像服务,整个流程大致如下图所示:

1527424471499000.png

基础准备

  1. 安装支持的 docker (http://rancher.com/docs/rancher/v1.6/en/hosts/#supported-docker-versions);
  2. 安装 Rancher v1.6.11 (https://hub.docker.com/u/rancher);
  3. 因为是对接云端 CI,所以 Rancher server 需要能被公网访问;
  4. 在 GitHub 创建一个 test 仓库并上传一个 Dkoerfile 文件,文件中只写 FROM busybox 一行代码;
  5. 去 https://requestb.net/ 创建一个 RequestBin,用于接收并查看阿里云 webhook 消息的内容;

测试服务准备

  1. 登录 Rancher WEB ,进入 应用 \ 用户视图,新建名为 app 的测试应用栈;

  2. 给应用打上 test=true 的标签,其他参数保存默认;

    1527424471489800.png1527424471973045.png

    PS:这个地方的标签,是为后面通过 webhook 升级时候调取服务用,需要保证标签的唯一性,不然相同标签的服务都会被升级 测试服务已经创建好,接下来创建一条 webhook 升级策略。四、添加 webhook 接收器

  3. 通过 API 进入 webhook,点击添加接收器,配置接收器:

    1527424471650964.png1527424471986742.png
    BASH
    名称:根据喜好填写;
    类型:选择升级服务;
    镜像仓库Webhook参数格式:目前可以选择阿里云或者docker hub
    镜像标签:这个标签对应仓库中构建镜像的标签
    服务选择器标签:这里填写创建服务时填写的标签;
    其他参数保持默认
  4. 接收器创创建好后,可以点击右侧的触发地址把地址复制到其他地方备用。

    1527424471112979.png

创建阿里云测试镜像仓库

  1. 通过 dev.aliyun.com 登录阿里云容器服务,进入控制台,点击右上角创建镜像仓库

    1527424472109055.png1527424472398412.png

    ps: 选择与你服务器所在的区域,镜像可以走内网下载。 找到刚刚创建的仓库,点击管理

    1527424472425306.png
  2. 添加一条 webhook,webhook URL 为 rancher-webhook 中复制的地址。

    1527424472478305.png

测试

  1. 修改并提交 test 代码仓库中的 Dockerfile 文件 在阿里云容器服务中查看构建进度

    1527424472617034.png1527424472840600.png1527424472963414.png1527424473384612.png

查看阿里云 webhook 的信息内容

  1. 复制 http://requestbin.net/ 中创建的 RequestBin 地址

    1527424473974408.png
  2. 再在阿里云云服务中添加一条 webhook

    1527424473499533.png
  3. 再次修改并提交 test 代码仓库中的 Dockerfile 文件,并进入 https://requestb.net 页面查看:

    1527424473406928.png
  4. 再对 RAW BODY 格式化:

    1527424473804069.png

收起阅读 »

Rancher 2.0 Training Camp回顾

[size=14]第1期:使用Rancher 2.0创建Kubernetes集群[/size] [size=14]课程大纲:[/size] [list=1] [*] [size=14]从零开始搭建一个简单的Rancher 2.0环境[/size][/*] [*...
继续阅读 »
第1期:使用Rancher 2.0创建Kubernetes集群
课程大纲:
  1. 从零开始搭建一个简单的Rancher 2.0环境
  2. 纳管现有的kubernetes集群
  3. 在Rancher 2.0上通过RKE创建一个kubernetes集群
  4. 使用Aliyun驱动创建一个kubernetes集群

回放地址:http://e.vhall.com/431874021
 
 
第2期:Rancher 2.0应用部署分享
课程大纲:
  1. Workload介绍
  2. Load Balancing 介绍
  3. Services Discovery 介绍
  4. Volume 介绍
  5. 如何部署一个简单应用
  6. 如何部署一个高可用应用
  7. 如何在Rancher上使用Yaml文件部署应用

回放地址:http://e.vhall.com/209459630
 
第3期:Kubernetes上的监控告警
课程大纲:
 
  1. 如何在2.0上对Kubernetes Cluster设置告警规则
  2. 如何在2.0上对Workload设置告警规则
  3. 如何集成Prometheus、Grafana等监控组件
  4. 如何使用prometheus的Kubernetes service discovery
  5. 如何给alert manager 配置告警规则

回放地址:http://e.vhall.com/163710123
 
 
第4期:使用Rancher 2.0进行多集群角色管理
课程大纲:
  1. 介绍kubernetes认证模型和RBAC授权模型
  2. Rancher 2.0多集群统一认证授权的实现原理
  3. 如何针对不同层级做角色授权管理

回放地址:https://e.vhall.com/829906699 收起阅读 »

Chain FORWARD (policy DROP)导致nginx容器使用NodePort无法相互访问

实现:nginx POD使用NodePort相互访问,即使用自己window电脑能访问所有节点的nignx的32065端口 环境如下: rancher2.0一台 node2 \ node3 \ node4 \ node5 四台节点 操作如下: 在rancher...
继续阅读 »
实现:nginx POD使用NodePort相互访问,即使用自己window电脑能访问所有节点的nignx的32065端口
环境如下:
rancher2.0一台
node2 \ node3 \ node4 \ node5 四台节点
操作如下:
在rancher2.0Web界面Workloads新建一个nginx POD, 设置“Port Mapping” 为NodePort  (使用NodePort类型的Service时会在集群内部所有host上暴露一个端口用于外部访问默认端口范围30000~32767) ,点击“upgrade”,生效后会在name名称为:"nginx4"下方显示一个端口号(32065端口)。
测试1,点击这个32065端口可以打开nignx访问页面。
测试2,所有节点可以访问本身的IP加32065端口号,如:127.0.0.1:32065或192.168.1.101:32065
测试3,所有节点可以访问nginx POD所在节点IP,如nginx POD所在节点node2(192.168.1.100),在node3\node4\node5节点上请求:curl 192.168.1.100:32065 ,应该可以正常访问。
测试4,所有节点可以相互访问对方IP:32065,即在node3请求其它节点IP,如:curl 192.168.1.101:32065或curl 192.168.1.102:32065
测试5,使用自己windows电脑能访问所有节点IP:32065
 
总结 ,注意事项:
1,关闭防火墙(只为测试) 
2,关闭selinux
3,打开cat  /proc/sys/net/ipv4/ip_forward 为1参数
4,查看iptables -t filter -L -n “Chain FORWARD (policy DROP)” 开启这项,执行:
#sudo iptables -P FORWARD ACCEPT
#service iptables save
  收起阅读 »

Rancher2-部署问题troubleshooting

[b]一、    环境需求[/b] 推荐使用的操作系统 •    Ubuntu 16.04 (64-bit) •    Red Hat Enterprise Linux 7.5 (64-bit) •    RancherOS 1.3.0 (64-bit) [...
继续阅读 »
一、    环境需求
推荐使用的操作系统
•    Ubuntu 16.04 (64-bit)
•    Red Hat Enterprise Linux 7.5 (64-bit)
•    RancherOS 1.3.0 (64-bit)

二、推荐的硬件配置
Deployment Size   Clusters        Nodes     vCPUs   RAM
Small             Up to 10        Up to 50   2      4GB
Medium            Up to 100       Up to 500  8      32GB

三、支持的docker版本
•    1.12.6
•    1.13.1
•    17.03.02

四、防火墙请允许通过已下端口
Protocol        Port range      Purpose   
tcp              22             ssh server
tcp              80             Rancher Server/ingress
tcp              443            Rancher Server/ingress
tcp              6443           kubernetes api server
tcp              2379-2380      etcd server client api
tcp              10250-10256    kubernetes components
tcp              30000-32767    nodeport services
udp              8472           canal

五、常见问题与排查思路
1、环境信息残留
 
目前部署中,大部分问题都是因为由于部署环境的操作系统,或多次部署,升级后残留的的信息造成的。部署前或部署时,请使用以下命令将环境的各类信息清理干净
df -h|grep kubelet |awk -F % '{print $2}'|xargs umount 
rm /var/lib/kubelet/* -rf
rm /etc/kubernetes/* -rf
rm /var/lib/rancher/* -rf
rm /var/lib/etcd/* -rf
rm /var/lib/cni/* -rf
rm -rf /var/run/calico 
iptables -F && iptables -t nat -F
ip link del flannel.1
docker ps -a|awk '{print $1}'|xargs docker rm -f
docker volume ls|awk '{print $2}'|xargs docker volume rm
rm -rf /var/etcd/
rm -rf /run/kubernetes/
docker rm -fv $(docker ps -aq)
docker volume rm  $(docker volume ls)
rm -rf /etc/cni
rm -rf /opt/cni
systemctl restart docker
 
2、openssh版本过低问题
centos或rhel系统并且版本低于7.4的,因为默认的openssh和openssl和红帽系ssh默认将AllowTcpForwarding 关闭了,rke部署时会出现如下问题

参考issue:https://github.com/rancher/rke/issues/93

需要您进行以下操作
a.    确保您的openssh版本大于等于7.x
b.    修改sshd配置打开AllowTcpForwarding=yes重启sshd
c.    默认centos和rhel不能使用root用户进行ssh tunnel,所以需要使用一个普通用户
d.    并将这个用户加入docker这个Group,useradd –G docker yourusername

3、nodeport端口只有一台机器能访问
只能访问一台宿主机的nodeport,并且还是pod所在那台机器,出现这种问题很大原因是因为,跨集群网络有问题,或本地防火墙问题,排查思路如下:
在宿主机本机telnet localhost:nodeort看看是否能通,本机能通,在集群内互相telnet测试,如果不能通根部署环境网络有很大关系,建议联系网络管理员进行排查。
如果本机telnet也不能通,进行如下测试。
a、首先我们需要或取对应的pod 信息


 
比如我这个test-6b4cdf4ccb-7pzt6在rancher-kf-worker01节点上,它的ip为10.42.3.23
 
b、先在pod所在的宿主机上然后在另外几个节点去ping这个ip,看看能否ping通,在canal网络模式下,请检查防火墙端口8472/UDP是否开放。查看每天机器上是否有尝试使用每台机器的flannel.1网卡,用的话,用flannel.1上的ip互相ping,看看是否能通,因为flannel网络和canal网络是通过flannel.1网卡互相建立vxlan遂道的。建议操作在关闭防火墙的情况下测试。

部署使用calico网络部署环境失败问题

部署rancher2.0时网络类型为calico时,如果cloud provider默认不填会选用公有云的,导致部署失败,所以这里我们需要手动填写为none。(后期会优化此项)

 
4、部署时主机not fount问题
出现这个问题是因为宿主机的主机名不符合kubernetes的标准主机名要求也不符合标准的linux主机名,主机名内不能有下划线。


 
5、获取组件健康状态forbidden问题


大部分原因是因为部署多次,证书残留的导致的,解决办法,按照环境信息残留里面的方法把环境清空下,在重新添加。
 
6、web页面kubectl闪退问题
这个主要根操作系统版本和浏览器的版本有关系,请使用上推荐使用操作系统中的操作系统,浏览器使用Chrome

7、非worker节点仍然被调度pod问题
目前rancher2.0非worker节点,仍然会被调度pod过去,您可以选择手动将它们从kube-scheduler踢除,命令如下:
打开web页面kubectl


 

然后执行
kubectl taint node rancher-kf-control01 node-role.kubernetes.io/rancher-kf-control01="":NoSchedule
kubectl taint node rancher-kf-control02 node-role.kubernetes.io/rancher-kf-control02="":NoSchedule
kubectl taint node rancher-kf-control03 node-role.kubernetes.io/rancher-kf-control03="":NoSchedule

8、it is a not share mount问题
 
部署时遇到share mount问题时,报错提示如下:
FATA[0180] [workerPlane] Failed to bring up Worker Plane: Failed to start [kubelet] container on host [192.168.10.51]: Error response from daemon: linux mounts: Path /var/lib/kubelet is mounted on / but it is not a shared mount.

这个问题原因主要是kubelet容器化部署,需要手动设置docker的MuntFLAGS为空
https://github.com/kubernetes/kubernetes/issues/4869#issuecomment-195696990
解决方法:
执行
mount --make-shared /
或配置docker.server
MountFlags=shared
重启docker.service
 
9、NetworkRedy=false问题


这个问题通常是,在部署时网络组件在初始化,在配置,等待段时间就好了。
 
10、集群unavailable


通常此问题,是因为rancher-server根kubernetes中的kube-apiserver 6443端口连接有问题,建议检查防火墙和查看kube-api-server的日志。
 
总结
1、部署时能严格按照官方给出的操作系统版本和docker版本部署,可以避免掉很多问题。
2、多次部署,升级,环境一定要按照环境信息残留章节的命令,将环境清理干净。
3、如果遇到问题,建议docker logs 查看rancher-agent,rancher-server的日志。 收起阅读 »

Rancher2 主机名命名规则

"2018-03-21T02:35:23Z","message": "Failed to deploy addon execute job: Job.batch \"rke-network-plugin-deploy-job\" is invalid: spe...
继续阅读 »
"2018-03-21T02:35:23Z","message": "Failed to deploy addon execute job: Job.batch \"rke-network-plugin-deploy-job\" is invalid: spec.template.spec.nodeName: Invalid value: \"chen-PC\": a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')","reason": "Error","status": 
"False","type": "Provisioned"}, 
 
因为K8S 主机名只支持- 和. (中横线和点),所以Rancher2添加的节点主机名 不能有除 -和 . 之外的特殊字符。 收起阅读 »

Rancher2.0 密码重置

登录rancher2.0 server主机,执行以下命令:   docker exec -ti  reset-password    返回以下信息: root@192-168-1-94:~# docker exec -ti agitated_liskov re...
继续阅读 »
登录rancher2.0 server主机,执行以下命令:
 
docker exec -ti  reset-password 
 
返回以下信息:
root@192-168-1-94:~# docker exec -ti agitated_liskov reset-password
New password for default admin user (user-vf4m5):
shhESE1e4tzMaDfc74nG
root@192-168-1-94:~# 收起阅读 »

Rancher 2.0 节点初始化

docker rm -f $(docker ps -qa) docker volume rm $(docker volume ls -q) for mount in $(mount | grep tmpfs | grep '/var/lib/kubel...
继续阅读 »
docker rm -f $(docker ps -qa)
docker volume rm $(docker volume ls -q)
for mount in $(mount | grep tmpfs | grep '/var/lib/kubelet' | awk '{ print $3 }') /var/lib/kubelet /var/lib/rancher; do umount $mount; done
rm -rf /etc/ceph \
/etc/cni \
/etc/kubernetes \
/opt/cni \
/opt/rke \
/run/secrets/kubernetes.io \
/run/calico \
/run/flannel \
/var/lib/calico \
/var/lib/etcd \
/var/lib/cni \
/var/lib/kubelet \
/var/lib/rancher \
/var/log/containers \
/var/log/pods \
/var/run/calico


完整文档: https://www.xtplayer.cn/rancher/node-init/

收起阅读 »

centos通过docker启动cAdvisor报错:/sys/fs/cgroup/cpuacct,cpu: no such file or directory

docker 启动 cAdvisor,操作系统CentOS7.4。 docker run \   --volume=/:/rootfs:ro \   --volume=/var/run:/var/run:rw \   --volume=/sys:/sys:r...
继续阅读 »
docker 启动 cAdvisor,操作系统CentOS7.4。

docker run \
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:rw \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --publish=8080:8080 \
  --detach=true \
  --name=cadvisor \
  --net=host \
   google/cadvisor:v0.28.3

发现容器没有正常启动,查看日志,有如下报错内容:
Failed to start container manager: inotify_add_watch /sys/fs/cgroup/cpuacct,cpu: no such file or directory
解决方法,执行:
mount -o remount,rw '/sys/fs/cgroup'
ln -s /sys/fs/cgroup/cpu,cpuacct /sys/fs/cgroup/cpuacct,cpu 收起阅读 »

rancher/server:1.6.16

[size=14]Release v1.6.16Versions[/size] [list] [*] rancher/server:v1.6.16[/*] [*] rancher/agent:v1.2.10[/*] [*] rancher/win-agent:...
继续阅读 »
Release v1.6.16Versions
Supported Docker Versions
  • Docker 1.12.3-1.12.6
  • Docker 1.13.1
  • Docker 17.03-ce/ee
  • Docker 17.06-ce/ee
  • Docker 17.09-ce/ee
  • Docker 17.12-ce/ee

Note: Kubernetes 1.9/1.8 supports Docker 1.12.6, 1.13.1 and 17.03.2. Kubernetes 1.7 supports up to Docker 1.12.6

Kubernetes VersionsList of images required to launch Kubernetes template:
  • rancher/k8s:v1.9.4-rancher1-1
  • rancher/etcd:v2.3.7-13
  • rancher/kubectld:v0.8.6
  • rancher/etc-host-updater:v0.0.3
  • rancher/kubernetes-agent:v0.6.7
  • rancher/kubernetes-auth:v0.0.8
  • rancher/lb-service-rancher:v0.7.17
  • busybox
For the list of versions for the Kubernetes add-ons embedded in the Rancher Kubernetes images, please refer to the kubernetes-package repo for the specific images and versions.Important - Kubernetes SecurityWIth this release, we are addressing several kubernetes vulnerabilities:[list=1]
  • The vulnerability CVE-2017-1002101 allows containers to use a subpath volume mount with any volume types to access files outside of the volume. This means that if you are blocking container access to hostpath volumes with PodSecurityPolicy, an attacker with the ability to update or create pods can mount any hostpath using any other volume type.
  • The vulnerability CVE-2017-1002102 allows containers using certain volume types - including secrets, config maps, projected volumes, or downward API volumes - to delete files outside of the volume. This means that if a container using one of these volume types is compromised, or if you allow untrusted users to create pods, an attacker could use that container to delete arbitrary files on the host.
  • Rancher is securing the kubelet port 10250 by no longer allowing anonymous access and requiring a valid cert. This is the port that is used by the kubernetes api-manager-to-kubelet communication and keeping this exposed will allow anonymous access to your compute node. Upgrading to the latest kubernetes version will resolve this issue. You can also visit the Rancher Docs site for specific instructions on how to secure your kubernetes cluster without upgrading your environment if you have not already done so previously.
  • Rancher v1.6.16 ships with k8s v.1.9.4 that addresses these vulnerabilities. If you are on Rancher v1.6.14 (current stable version) or v1.6.13, you will also be prompted with an update to your existing k8s v1.8.5 to v1.8.9. We highly recommend you to upgrade as soon as possible.Important - Upgrade
    • Users on a version prior to Rancher v1.5.0: We will automatically upgrade the 
      network-services
       infrastructure stack as without this upgrade, your release will not work.
    • Users on a version prior to Rancher v1.6.0: If you make any changes to the default Rancher library setting for your catalogs and then roll back, you will need to reset the branch used for the default Rancher library under Admin -> Settings -> Catalog. The current default branch is 
      v1.6-release
      , but the old default branch is 
      master
    • Rollback Versions: We support rolling back to Rancher v1.6.14 from Rancher v1.6.16.
      • Steps to Rollback:
        • In the upgraded version the Admin -> Advanced Settings -> API values, update the 
          upgrade.manager
           value to 
          all
        • "Upgrade" Rancher server but pointing to the older version of Rancher (v1.6.14). This should include backing up your database and launching Rancher to point to your current database.
        • Once Rancher starts up again, all infrastructure stacks will automatically rollback to the applicable version in v1.6.14.
        • After your setup is back to its original state, update the 
          upgrade.manager
           value back to the original value that you had (either 
          mandatory
           or 
          none



         

        Note on Rollback: If you are rolling back and have authentication enabled using Active Directory, any new users/groups added to site access on the Access Control page after the upgrade will not be retained upon rolling back. Any users added before the upgrade will continue to remain. [#9850]
         


        收起阅读 »