2022年1月

探索 Kubernetes 中不同容器日志记录模式的工作原理。

 title=

服务器和应用程序日志记录是开发人员、运维人员和安全团队了解应用程序在其生产环境中运行状态的重要工具。

日志记录使运维人员能够确定应用程序和所需组件是否运行平稳,并检测是否发生了异常情况,以便他们能够对这种情况做出反应。

对于开发人员,日志记录提供了在开发期间和之后对代码进行故障排除的可见性。在生产环境中,开发人员通常依赖于没有调试工具的日志记录工具。在加上系统的日志记录,开发人员可以与运维人员携手合作,有效地解决问题。

日志记录工具最重要的受益者是安全团队,尤其是在云原生的环境中。能够从应用程序和系统日志中收集信息使得安全团队能够分析来自身份验证、应用程序访问恶意软件活动的数据,并在需要时进行响应。

Kubernetes 是领先的容器平台,越来越多的应用程序通过 Kubernetes 部署到生产环境。我相信了解 Kubernetes 的日志架构是一项非常重要的工作,每个开发、运维和安全团队都需要认真对待。

在本文中,我将讨论 Kubernetes 中不同容器日志记录模式的工作原理。

系统日志记录和应用日志记录

在深入研究 Kubernetes 日志记录架构之前,我想探索不同的日志记录方法以及这两种功能如何成为 Kubernetes 日志记录的关键特性。

有两种类型的系统组件:在容器中运行的组件和不在容器中运行的组件。例如:

  • Kubernetes 调度者和 kube-proxy 运行在容器中。
  • kubelet 和容器运行时不在容器中运行。

与容器日志类似,系统容器日志存储在 /var/log 目录中,你应该定期轮换它们。

在这里,我研究的是容器日志记录。首先,我看一下集群级别的日志记录以及为什么它对集群运维人员很重要。集群日志提供有关集群如何执行的信息。诸如为什么 吊舱 Pod 被下线或节点死亡之类的信息。集群日志记录还可以捕获诸如集群和应用程序访问以及应用程序如何利用计算资源等信息。总体而言,集群日志记录工具为集群运维人员提供操作集群和安全有用的信息。

捕获容器日志的另一种方法是通过应用程序的本机日志记录工具。现代应用程序设计很可能具有日志记录机制,可帮助开发人员通过标准输出 (stdout) 和错误流 (stderr) 解决应用程序性能问题。

为了拥有有效的日志记录工具,Kubernetes 实现需要应用程序和系统日志记录组件。

Kubernetes 容器日志的 3 种类型

如今,在大多数的 Kubernetes 实现中,你可以看到三种主要的集群级日志记录方法。

  1. 节点级日志代理
  2. 用于日志记录的 挎斗 Sidecar 容器应用程序
  3. 将应用程序日志直接暴露给日志后端

节点级日志代理

我想考虑节点级日志代理。你通常使用 DaemonSet 作为部署策略来实现这些,以便在所有 Kubernetes 节点中部署一个吊舱(充当日志代理)。然后,该日志代理被配置为从所有 Kubernetes 节点读取日志。你通常将代理配置为读取节点 /var/logs 目录捕获 stdout/stderr 流并将其发送到日志记录后端存储。

下图显示了在所有节点中作为代理运行的节点级日志记录。

 title=

以使用 fluentd 方法为例设置节点级日志记录,你需要执行以下操作:

1、首先,你需要创建一个名为 fluentdd 的服务账户。Fluentd 吊舱使用此服务账户来访问 Kubernetes API,你需要在日志命名空间中使用标签 app: fluentd 创建它们:

#fluentd-SA.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: fluentd
  namespace: logging
  labels:
    app: fluentd  

你可以在此 仓库 中查看完整示例。

2、接着,你需要创建一个名称为 fluentd-configmap 的 ConfigMap。这为 fluentd daemonset 提供了一个配置文件,其中包含所有必需的属性。

#fluentd-daemonset.yaml
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: logging
  labels:
    app: fluentd
    kubernetes.io/cluster-service: "true"
spec:
  selector:
    matchLabels:
      app: fluentd
      kubernetes.io/cluster-service: "true"
  template:
    metadata:
      labels:
        app: fluentd
        kubernetes.io/cluster-service: "true"
    spec:
      serviceAccount: fluentd
      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1.7.3-debian-elasticsearch7-1.0
        env:
          - name: FLUENT_ELASTICSEARCH_HOST
            value: "elasticsearch.logging.svc.cluster.local"
          - name: FLUENT_ELASTICSEARCH_PORT
            value: "9200"
          - name: FLUENT_ELASTICSEARCH_SCHEME
            value: "http"
          - name: FLUENT_ELASTICSEARCH_USER
            value: "elastic"
          - name: FLUENT_ELASTICSEARCH_PASSWORD
            valueFrom:
              secretKeyRef:
                name: efk-pw-elastic
                key: password
          - name: FLUENT_ELASTICSEARCH_SED_DISABLE
            value: "true"
        resources:
          limits:
            memory: 512Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
        - name: fluentconfig
          mountPath: /fluentd/etc/fluent.conf
          subPath: fluent.conf
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers
      - name: fluentconfig
        configMap:
          name: fluentdconf

你可以在此 仓库 中查看完整示例。

现在,我们来看看如何将 fluentd daemonset 部署为日志代理的代码。

#fluentd-daemonset.yaml
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: logging
  labels:
    app: fluentd
    kubernetes.io/cluster-service: "true"
spec:
  selector:
    matchLabels:
      app: fluentd
      kubernetes.io/cluster-service: "true"
  template:
    metadata:
      labels:
        app: fluentd
        kubernetes.io/cluster-service: "true"
    spec:
      serviceAccount: fluentd
      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1.7.3-debian-elasticsearch7-1.0
        env:
          - name: FLUENT_ELASTICSEARCH_HOST
            value: "elasticsearch.logging.svc.cluster.local"
          - name: FLUENT_ELASTICSEARCH_PORT
            value: "9200"
          - name: FLUENT_ELASTICSEARCH_SCHEME
            value: "http"
          - name: FLUENT_ELASTICSEARCH_USER
            value: "elastic"
          - name: FLUENT_ELASTICSEARCH_PASSWORD
            valueFrom:
              secretKeyRef:
                name: efk-pw-elastic
                key: password
          - name: FLUENT_ELASTICSEARCH_SED_DISABLE
            value: "true"
        resources:
          limits:
            memory: 512Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
        - name: fluentconfig
          mountPath: /fluentd/etc/fluent.conf
          subPath: fluent.conf
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers
      - name: fluentconfig
        configMap:
          name: fluentdconf

将这些放在一起执行:

kubectl apply -f fluentd-SA.yaml \
              -f fluentd-configmap.yaml \
              -f fluentd-daemonset.yaml

用于日志记录的挎斗容器应用程序

另一种方法是使用带有日志代理的专用挎斗容器。容器最常见的实现是使用 Fluentd 作为日志收集器。在企业部署中(你无需担心一点计算资源开销),使用 fluentd(或类似)实现的挎斗容器提供了集群级日志记录的灵活性。这是因为你可以根据需要捕获的日志类型、频率和其它可能的调整来调整和配置收集器代理。

下图展示了作为日志代理的挎斗容器。

 title=

例如,一个吊舱运行单个容器,容器使用两种不同的格式写入两个不同的日志文件。吊舱的配置文件如下:

#log-sidecar.yaml
apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox
    args:
   - /bin/sh
    - -c
    - >
     i=0;
      while true;
      do
        echo "$i: $(date)" >> /var/log/1.log;
        echo "$(date) INFO $i" >> /var/log/2.log;
        i=$((i+1));
        sleep 1;
      done
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-log
    image: busybox
    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}

把它们放在一起,你可以运行这个吊舱:

$ kubectl apply -f log-sidecar.yaml

要验证挎斗容器是否用作日志代理,你可以执行以下操作:

$ kubectl logs counter count-log

预期的输出如下所示:

$ kubectl logs counter count-log-1

Thu 04 Nov 2021 09:23:21 NZDT
Thu 04 Nov 2021 09:23:22 NZDT
Thu 04 Nov 2021 09:23:23 NZDT
Thu 04 Nov 2021 09:23:24 NZDT

将应用程序日志直接暴露给日志后端

第三种方法(在我看来)是 Kubernetes 容器和应用程序日志最灵活的日志记录解决方案,是将日志直接推送到日志记录后端解决方案。尽管此模式不依赖于原生 Kubernetes 功能,但它提供了大多数企业需要的灵活性,例如:

  1. 扩展对网络协议和输出格式的更广泛支持。
  2. 提供负载均衡能力并提高性能。
  3. 可配置为通过上游聚合接受复杂的日志记录要求。

因为这第三种方法通过直接从每个应用程序推送日志来依赖非 Kubernetes 功能,所以它超出了 Kubernetes 的范围。

结论

Kubernetes 日志记录工具是企业部署 Kubernetes 集群的一个非常重要的组件。我讨论了三种可能的可用模式。你需要找到适合你需求的模式。

如上所述,使用 daemonset 的节点级日志记录是最容易使用的部署模式,但它也有一些限制,可能不适合你的组织的需要。另一方面,挎斗 模式提供了灵活性和自定义,允许你自定义要捕获的日志类型,但是会提高计算机的资源开销。最后,将应用程序日志直接暴露给后端日志工具是另一种允许进一步定制的诱人方法。

选择在你,你只需要找到适合你组织要求的方法。


via: https://opensource.com/article/21/11/cluster-logging-kubernetes

作者:Mike Calizo 选题:lujun9972 译者:perfiffer 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

美国一州长重申将起诉查看网站源代码的记者

去年 10 月,一名美国记者使用浏览器自带的工具查看了美国密苏里州教育部门网站的网页源代码,发现其在网页中泄露了所有教师和管理人员的社会安全号码。他向该州政府报告了该问题,并在漏洞得到解决后才公开发布了这个事情。美国联邦调查局很早就告诉该州的官员,“这次事件并不是真正的网络入侵事件”。该州教育部门最初还写了一份新闻稿,感谢记者提醒他们注意此事。但该州州长坚持认为记者是黑客,并命令密苏里州公路巡警对他们进行“调查”,以便起诉。这一决定引来舆论大哗,但该州州长本周召开新闻发布会,重申将起诉记者,因为他们揭露了他自己的政府运行了一个危险的计算机系统,使 60 万州雇员的私人信息面临危险。

老王点评:这世界就是因为这些愚蠢的官僚显现出几分滑稽。

深度学习不可信

过去 20 年,深度学习透过一系列商业应用逐渐主导了人工智能研究和应用。专家认为,该技术是 不可信的,因为它无法解释,而且不适用于某些应用,因为它会经历灾难性的遗忘。换言之,如果算法有效,无法理解它为什么有效。而当该工具慢慢学习新数据库时,其学习记忆的任意部分可能会突然崩塌。因此在任何攸关生死的应用(例如医疗应用)上使用深度学习都可能存在风险。

老王点评:虽然 AI 也确实在很多领域发挥了重要作用,或具有神奇的效果,但或许我们现在对 AI 的认识还只是盲人摸象。

CentOS Linux 8 到达生命终点

一年前红帽公司宣布他们将重点转移到 CentOS Stream 上,作为红帽企业 Linux(RHEL)的新上游。今年以来,CentOS Stream 已经初具规模,而这意味着 CentOS Linux 8 的完结。昨天,CentOS 8 正式到达终点,不会再有对它的支持和维护。之前发布的 RHEL 8.5 以及伴随的 CentOS 8.5 将成为绝响。

老王点评:CentOS 的落幕具有里程碑意义,我们将迎来一个没有 CentOS 的时代,这或许是好事,或许不是。

如果你最开始使用的是 Windows 电脑,你很可能会使用“ 文件夹 folder ”这个术语。

但当你换到 Linux 时,你会发现文件夹通常被称为“ 目录 directory ”。

这可能使一些新的 Linux 用户感到困惑。你应该叫它文件夹还是目录?它们有区别吗?

事情是这样的。如果你愿意,你可以叫它文件夹,如果你喜欢,也可以叫它目录。这没有什么区别。

但是,如果你想知道为什么文件夹在 Linux 中被称为目录,这里有一些解释。

为什么在 Linux 中文件夹被称为目录?

在我解释之前,让我们回顾一下文件夹和目录在现实世界中的用途。

在现实中,文件夹(封套)可以用来保存几个文件(或其他项目)。而目录则可以用来维护项目的索引,这样你就可以找到哪个项目位于哪里。

文件夹和目录的示意

现在,让我们回到目录。这个词甚至在 Linux 存在之前就已经存在了。它来自 UNIX 时代。Linux 继承了 UNIX 的很多东西,这只是其中的一个。

现在让我告诉你一些可能让你吃惊的事情。目录并不是真的把文件放在里面。目录是一个“特殊的文件”,它知道文件在存储中的位置(通过 inode)。

这就说明了为什么它被称为目录。目录用来保存项目的索引,而不用保存项目本身。Linux 和 UNIX 中的目录并不保存它里面的文件。它们只是记录文件位置的信息。

如果你想了解更多关于它的信息,我这篇关于 硬链接 的文章应该可以帮助你。

那么,为什么它被称为文件夹呢?依我看,这是视角的原因。当你在一个图形环境中时,你会将事物可视化。在这里,文件可以像页面一样被可视化,这些文件页面被存储在一个封套(文件夹)中。

当操作系统开始使用图形元素时,我认为一些术语也相应地发生了变化,目录 -> 文件夹就是其中之一。

你应该叫它文件夹还是目录?

这完全取决于你。你可以按你的习惯使用这两个术语。

然而,如果你正在学习 Linux 命令行或经常使用它,使用目录这个术语可能会有一点帮助。

有一些 Linux 命令,如 mkdirrmdir 等,术语 “dir” 给出了一个提示,即这些命令与目录有关。

同样,许多 Linux 命令和 bash 脚本会使用选项 -d 表示目录,-f 表示文件。

甚至终端中的文件属性也会通过在目录前面加上字母 “d” 来区分文件和文件夹(目录)。

拿这个例子来说,我有一个名为 some 的文件和一个名为 something 的文件夹/目录。请注意各种 Linux 命令是如何用 “dir” 或 “d” 来区分文件和目录的。

显示文件和目录操作之间区别的例子

所有这些让我觉得,在使用 Linux 命令时,使用 “目录” 这个术语会有好处。你的潜意识会更容易将 “dir” 和 “d” 与目录联系起来。

再说一次,你想叫它文件夹或目录这完全取决于你。人们会明白你指的是什么。

我刚刚对目录一词的历史渊源做了一些分析,这应该会给你一些提示,为什么人们说 “在 Linux/UNIX 中,所有东西都是一个文件”。

现在我结束了我的胡言乱语,我请你对它进行评论。如果你发现任何技术上的不准确之处,请告诉我。


via: https://itsfoss.com/folder-directory-linux/

作者:Abhishek Prakash 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

除了 System76 宣布了基于 RUST 的新桌面环境之外,还有别的团队也给桌面 Linux 用户带来了一些新东西。

过去的几年里,我们很欣慰地看到 Nitrux Linux 背后的团队正在扩大他们对 Linux 社区的影响。如今,伴随着全新 Maui Shell 的发布,他们的影响也已经得到了进一步扩大。

让我们一起来看看吧!

关于 Maui 项目的一些背景介绍

作为由 Nitrux Linux 团队原班人马创建、开发、维护的项目,Maui 项目已经开发了许多基础应用。实际上,他们的文件管理器 Index 甚至成功进入了我们的 2021 年五大应用列表 之中!

他们的所有应用均使用 MauiKit 这款定制框架开发。基于 Kirigami 的 MauiKit 专注于跨终端融合性,因此开发出来的应用可以在电脑和手机端拥有一致的体验。此外,它为开发者提供了更多的预置组件,因此创建应用可以更加便捷。

目前 Maui 项目开发的部分应用包括:

  • Index(文件管理器)
  • Nota(文本编辑器)
  • VVave(音乐播放器)
  • Clip(视频播放器)
  • Pix(图片查看器)

虽然这些自制应用本身质量不错,但它们在 Nitrux Linux 的默认桌面环境 KDE Plasma 里总显得不合群。因此,Maui Shell 应运而生。

Maui Shell 介绍

借助与 Maui 应用相同的 MauiKit 和 Qt 技术底层,Maui Shell 是 Nitrux 在桌面环境领域的一个新尝试。从上面的截图可以看出,它在很大程度上受到了 GNOME Shell 的启发,这在使用过程中也确实有所体现。

但,这并不意味着 Maui Shell 没有原创的地方。从底部上滑可打开类似于 GNOME “活动”的概览界面。与此相邻的是一个小 Dock,可以通过相当美观的启动器来启动应用。右上角有一个与 macOS 相似的控制中心,内有精心设计的菜单和许多控制功能。

在我使用它的过程中,一切都是如此精致、自然。我感觉这与它极致现代、扁平的设计美学有关,我甚至认为 Maui Shell 已经超越了 GNOME 和 KDE Plasma 等同类软件。说到 Plasma,与 Nitrux 的默认 Plasma 版本相比,Maui Shell 在低端设备(和虚拟机)上的反应更加灵敏。

总的来说,我预测 Maui Shell 将依靠其实用性成为 “Linux 桌面环境之王”。然而,我还没谈到 Maui Shell 最核心的特性: 跨终端自适应性 Convergence

主流之中的融合

许多人可能还记得 2010 年 Canonical 开发了一款类似的跨终端桌面环境 Unity,它最终以失败落幕,到 2018 年则被完全淘汰了。但是,Unity 和 Maui Shell 有一个共同特性 —— 那就是跨终端融合性。

随着 Linux 在移动端的开发力度逐渐加大,跨终端支持变得尤为重要。由此来看,一个新的桌面环境竟能同时支持桌面端和移动端,的确不可思议。

这一点必须依靠大量的跨终端应用实现,而 Maui 已经处在了完美的衔接点上。这仅仅是我相信 Maui Shell 能成为 Linux 桌面未来的原因之一。

立即试用 Maui Shell

与其他新发布的软件不同,Maui Shell 已经预装于新发布的 Nitrux 1.8。如果你想亲自尝试一下,那请随时从下方链接中获取 ISO 镜像。但是,在尝试之前,请务必知晓:Maui Shell 仍处于早期开发阶段。

尽管 Maui Shell 拥有许多特色功能,但部分功能可能存在问题、尚未实现,要么就是缺失了,其中包括:

  • 蓝牙支持
  • PulseAudio 支持
  • 网络开关
  • 媒体控制(MPRIs)
  • 拖放支持
  • 多显示器支持
  • 设置应用
  • XWayland Shell 插件

因此,我暂时不能建议你使用 Maui Shell 作为主力桌面环境。为此,你可能需要等待 2022 年秋季发布的正式版本。

在此之前,我仍将持续关注 Maui Shell。对于这款桌面环境,你的评价如何?欢迎在评论区说出你的想法!


via: https://news.itsfoss.com/maui-shell-unveiled/

作者:Jacob Crume 选题:lujun9972 译者:imgradeone 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出