在kubernetes中等效的depends_on是什么

Question

我有一个包含以下条目的docker compose文件

---

version: '2.1'

services:
  mysql:
    container_name: mysql 
    image: mysql:latest 
    volumes:
      - ./mysqldata:/var/lib/mysql 
    environment: 
      MYSQL_ROOT_PASSWORD: 'password' 
    ports: 
      - '3306:3306' 
    healthcheck: 
        test: ["CMD", "curl", "-f", "http://localhost:3306"] 
        interval: 30s 
        timeout: 10s 
        retries: 5 

  test1: 
    container_name: test1 
    image: test1:latest 
    ports: 
      - '4884:4884' 
      - '8443' 
    depends_on: 
      mysql: 
        condition: service_healthy 
    links: 
     - mysql 

Test-1容器依赖于mysql，并且需要启动并运行。

在docker中，可以使用运行状况检查和Depends_on属性来控制它。kubernetes中的运行状况检查等效项是我已经创建的readinessprobe，但是我们如何控制吊舱中容器的启动？

任何方向对此表示极大的赞赏。

我的Kubernetes文件：

apiVersion: apps/v1beta1 
kind: Deployment 
metadata: 
  name: deployment 
spec: 
  replicas: 1 
  template: 
    metadata: 
      labels: 
        app: deployment 

    spec: 
      containers: 
      - name: mysqldb 
        image: "dockerregistry:mysqldatabase" 
        imagePullPolicy: Always 
        ports: 
        - containerPort: 3306 
        readinessProbe: 
          tcpSocket: 
            port: 3306 
          initialDelaySeconds: 15 
          periodSeconds: 10 
      - name: test1 
        image: "dockerregistry::test1" 
        imagePullPolicy: Always 
        ports: 
        - containerPort: 3000 

Answer 1

那就是Docker Compose和Docker Swarm的美丽……它们的简单性。

部署ELK堆栈时，我们也遇到了同样的Kubernetes缺点。我们通过使用小车（initContainer）来解决了这个问题，这是同一个容器中首先运行的另一个容器，当它完成后，kubernetes会自动启动[main]容器。我们制作了一个简单的shell脚本，该脚本一直循环运行，直到Elasticsearch启动并运行，然后退出并启动Kibana的容器。

下面是一个等待Grafana准备就绪的边车的示例。

在Pod中的其他容器上方添加此“ initContainer”块：

spec:
      initContainers:
      - name: wait-for-grafana
        image: darthcabs/tiny-tools:1
        args:
        - /bin/bash
        - -c
        - >
          set -x;
          while [[ "$(curl -s -o /dev/null -w ''%{http_code}'' http://grafana:3000/login)" != "200" ]]; do 
            echo '.'
            sleep 15;
          done
      containers:
          .
          .
  (your other containers)
          .
          .

Answer 2

故意将其排除在外。原因是应用程序应负责其连接/重新连接逻辑，以连接到数据库之类的服务。这超出了Kubernetes的范围。

Answer 3

虽然除了此链接 (k8s-AppController) 之外，我不知道您问题的直接答案，但我认为对 DB 和应用程序使用相同的部署是不明智的。因为您正在将您的数据库与应用程序紧密耦合，并失去了很棒的 k8s 选项来根据需要扩展其中的任何一个。此外，如果您的 db pod 死亡，您也会丢失数据。

就我个人而言，我会做的是为数据库和应用程序部署一个单独的带有持久卷的StatefulSet，并使用Service来确保它们的通信。 是的，我必须运行几个不同的命令，并且可能需要至少两个单独的部署文件，但这样我就可以将它们解耦并可以根据需要扩展它们。而且我的数据也是持久的！

Answer 4

如前所述，您应该在单独的 Pod 中运行数据库和应用程序容器，并将它们与服务连接。

不幸的是，Kubernetes 和 Helm 都不提供与您所描述的类似的功能。我们遇到了很多问题，并尝试了几种方法，直到我们决定开发一个小型实用程序来为我们解决这个问题。

以下是我们开发的工具的链接：https://github.com/Opsfleet/depends-on

您可以让 Pod 等待，直到其他 Pod 根据其 readinessProbe 配置准备就绪。它与 Docker 的 dependent_on 功能非常接近。