Kubernetes 侧车与 MinIO

AJ AJ 于 Kubernetes 2023年10月20日

关注：领英 X

MinIO 是组织中多个应用程序依赖的核心基础设施组件。MinIO 为一些最苛刻的云原生应用程序提供支持，例如数据库外部表存储、指标和日志存储、配置管理数据、数据湖中的 AI/ML 数据、使用 Apache Spark 进行大数据处理、Helm 图表存储库等等。

MinIO 旨在可在任何地方运行。它可以在本地、公有云或私有云、边缘 IoT 设备、虚拟机、Docker 容器和 Kubernetes 上运行——任何你需要兼容 S3 API 的对象存储的地方。我们尤其重视 Kubernetes，因为我们认为它是应用程序部署和编排的未来。我们在开发 MinIO 时充分考虑了 Kubernetes，并提供了不同的部署方式，例如独立集群或使用操作符的多个租户。

无论您使用哪种方法将 MinIO 部署到 Kubernetes 中，最终您的应用程序都需要通过我们提供的 API 或 SDK 与其交互此处。需要注意的是，有时您需要在对象或集群上执行与主应用程序分离的任务。这些任务是什么呢？

如果您有单独的应用程序，则 sidecar 可以管理日志记录
应用程序的即席配置以及在需要时重新加载
sidecar 可以处理 TLS 终止

为了执行这些各种任务，您可以将其作为 sidecar 在与主应用程序相邻的单独容器中运行，而不是修改主应用程序或其正在运行的容器。

什么是 Sidecar？

Kubernetes 中提供了如此多种不同的资源类型，有时甚至无法知道要将哪种资源用于特定目的。Sidecar 不是 Pod、Deployment、StatefulSet、DaemonSet 等特定资源类型。它只是一个容器，就像 `Pod` 资源启动的容器一样。通常，一个 Pod 只包含一个具有特定用途的容器。但有时您需要在同一个 Pod 中部署两个容器，也许是由于上述原因，这个第二个容器被称为“sidecar”。

sidecar 容器与主容器共享相同的资源，例如网络空间和存储卷。这允许主容器访问 sidecar 中的数据，反之亦然，并允许它们使用其本地 IP 而不是 Kubernetes DNS 名称相互通信。

带有 MinIO 的 Sidecar

随着 MinIO 作为基础设施运营中的核心基础组件，数据需要随时可用，集群需要可扩展，而且在出现硬件问题时需要容错，这不足为奇。由于 MinIO 的多功能性和与 Kubernetes 的集成，它们经常被配对使用，因为它们支持无数的应用程序用例。

图像调整大小

在去年的Kafka 博客文章中，我们讨论了一个图像调整大小工作流，该工作流允许您从 MinIO 存储桶中获取图像，然后使用侦听 Kafka 消息的 Python 脚本对其进行调整大小。

例如，您可以将该脚本（下面显示的代码段）在 Kubernetes sidecar 容器中运行，该容器将侦听 Kafka 消息，然后在 sidecar 容器中执行调整大小操作。

from minio import Minio
import urllib3

from kafka import KafkaConsumer
import json
…

# Initialize MinIO client
minio_client = Minio(config["minio_endpoint"],
               secure=True,
               access_key=config["minio_username"],
               secret_key=config["minio_password"],
               http_client = http_client
               )

…

# Initialize Kafka consumer
consumer = KafkaConsumer(
  bootstrap_servers=config["kafka_servers"],
  value_deserializer = lambda v: json.loads(v.decode('ascii'))
)

consumer.subscribe(topics=config["kafka_topic"])

try:
  print("Ctrl+C to stop Consumer\n")
  for message in consumer:
    message_from_topic = message.value

    request_type = message_from_topic["EventName"]
    bucket_name, object_path = message_from_topic["Key"].split("/", 1)

    # Only process the request if a new object is created via PUT
    if request_type == "s3:ObjectCreated:Put":
      minio_client.fget_object(bucket_name, object_path, object_path)
     
       print("- Doing some pseudo image resizing or ML processing on %s" % object_path)

      minio_client.fput_object(config["dest_bucket"], object_path, object_path)
…

这是最佳部分。您的主应用程序可以使用完全不同的语言及其自己的依赖项，与 sidecar 容器分离。例如，sidecar 可以是我们的 Python 脚本，而主应用程序可以使用 Golang。

备份

备份通常需要大量时间才能完成，并且每个备份都需要在不同的时间使用其自己的资源运行。这样，它们就不会干扰主应用程序的性能。因此，虽然数据库或配置可能正在主容器上运行，但备份将在 sidecar 容器中运行，并使用Jumbo加速。

在MongoDB 中，您将在 sidecar 中运行以下命令

mongodump --db=examples --collection=movies --out="-" | ./jumbo_0.1-rc2_linux_amd64 put http://<Your-MinIO-Address>:9000/backup/mongo-backup-1

在Percona DB 中，它看起来像这样

xtrabackup --backup --compress --compress-threads=8 --stream=xbstream --parallel=4 --target-dir=./ | backup.xbstream gzip -`` | ./jumbo_0.1-rc2_linux_amd64 put https://:20091/testbackup123/percona-xtrabackup

依此类推。您可以对任何类型的数据存储进行类似的重复操作。

其他用例

我们可以整天谈论这个话题，但概括来说，sidecar 最常见的用例之一是监控。例如，使用OpenTelemetry，您可以通过在 sidecar 容器中运行代理来发送集群和 Pod 指标。在需要分布式跟踪的应用程序中，您可以在 sidecar 中运行 Jaeger 以收集跟踪并将其发送到您选择的任何指标服务器，例如 Prometheus、OpenTelemetry 或 InfluxDB。

另一个突出的用例是配置管理，例如Puppet 和 Salt，甚至etcd 和Consul，其中配置管理数据需要每隔几分钟同步一次。这是一个重复性任务，sidecar 可以持续运行，以便应用程序始终拥有最新最好的配置。即使 sidecar 由于某种原因而出现故障，它也会继续使用上次已知成功同步的配置。

Sidecar 示例

让我们启动一个小应用程序来了解使用 Kubernetes sidecar 容器的基础知识，以及如何在应用程序和 MinIO 旁边使用它们。

在深入研究启动 sidecar 之前，让我们看看配置它有多简单。在 `spec.containers` 下，您将添加如下条目。

apiVersion: v1
kind: Pod
spec:
  containers:
    - name: main-application
      image: nginx
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx

如果您注意到这是一个容器“列表”。要添加 sidecar，只需在列表底部添加另一个容器，如下所示

apiVersion: v1
kind: Pod
spec:
  containers:
    - name: main-application
      image: nginx
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx
    - name: sidecar-container
      image: busybox
      command: ["sh","-c","while true; do cat /var/log/nginx/access.log; sleep 30; done"]
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx
  volumes:
    - name: shared-logs
      emptyDir: {}

就是这样，这就是 sidecar。只需执行此操作，您就授予了第二个容器访问所有数据和网络空间到主容器以及反向访问的权限。

此示例应用程序基本上读取主容器的日志并将其输出到 Kubernetes 日志。为了访问服务，我们需要在 NodePort 上公开它。

apiVersion: v1
kind: Service
metadata:
  name: simple-webapp
  labels:
    run: simple-webapp
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: webapp
  type: NodePort

将此 YAML 与 Deployment 和 Service 应用到您选择的 Kubernetes 集群中。在本例中，我们使用的是 Minikube 集群。

kubectl create -f <sidecar>.yaml

使用以下命令在 minikube 中公开我们创建的服务

minikube service --url simple-webapp

查看 sidecar 容器的日志

kubectl logs -f simple-webapp sidecar-container

使用浏览器访问 Nginx 服务器

您应该在 sidecar 容器日志中看到类似以下内容

伙伴系统

作为一个狂热的摩托车爱好者，sidecar 让我想起了那些老式的摩托车，您可以在旁边的小型类似于敞篷车的座位上搭载乘客。这些东西以难以驾驶而闻名，事情也可能很快失控。

Kubernetes sidecar 也是如此。您不仅可以拥有一个 sidecar，还可以拥有多个在 Pod 中运行的 sidecar。除了主容器之外的任何容器都被视为 sidecar，但要谨慎行事，仅仅因为 Kubernetes 允许这样做并不意味着我们应该拥有一个充满 sidecar 的大型单体应用程序。您仍然希望为不同的应用程序拥有不同的 Pod 和部署，并且在开发应用程序时通常遵循最佳实践。当您有两个不同的应用程序但它们以某种方式相互补充时，sidecar 很有用，例如日志记录、监控或任何其他有助于主应用程序的任务。

有关 Sidecar 和 Kubernetes 的更多信息，请使用博客右下角的实时聊天与我们的专家联系，并通过发送电子邮件至 hello@min.io 了解有关我们的SUBNET 体验的更多信息。