AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

Kubernetes StatefulSets有状态应用

2022-12-12 213
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云解析 DNS，旗舰版 1个月
公共DNS（含HTTPDNS解析），每月1000万次HTTP解析
全局流量管理 GTM，标准版 1个月
简介： Kubernetes StatefulSets有状态应用

Kubernetes StatefulSet

tags: StatefulSet

文章目录

Kubernetes StatefulSet

0. 简介

1. 创建 StatefulSet

2. 扩容/缩容 StatefulSet

2.1 扩容

2.2 缩容

3. 更新 StatefulSet

3.1 Rolling Update 策略

3.2 分段更新

3.3 灰度发布

4. 删除 StatefulSet

4.1 非级联删除

4.2 级联删除

5. Pod 管理策略

5.1 Parallel Pod 管理策略

6. 示例

0. 简介

StatefulSet 是用来管理有状态应用的工作负载 API 对象。


StatefulSet 用来管理 Deployment 和扩展一组 Pod，并且能为这些 Pod 提供序号和唯一性保证。


和 Deployment 相同的是，StatefulSet 管理了基于相同容器定义的一组 Pod。但和 Deployment 不同的是，StatefulSet 为它们的每个 Pod 维护了一个固定的 ID。这些 Pod 是基于相同的声明来创建的，但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。


StatefulSet 和其他控制器使用相同的工作模式。你在 StatefulSet 对象 中定义你期望的状态，然后 StatefulSet 的 控制器 就会通过各种更新来达到那种你想要的状态。


使用 StatefulSets

1. 创建 StatefulSet

它创建了一个 Headless Service nginx 用来发布 StatefulSet web 中的 Pod 的 IP 地址。

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

你需要使用两个终端窗口。在第一个终端中，使用 kubectl get 来查看 StatefulSet 的 Pods 的创建情况。

kubectl get pods -w -l app=nginx

在另一个终端中，使用 kubectl apply来创建定义在 web.yaml 中的 Headless Service 和 StatefulSet。

$ kubectl apply -f web.yaml
service/nginx created
statefulset.apps/web created
$ kubectl get service nginx
NAME      TYPE         CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
nginx     ClusterIP    None         <none>        80/TCP    12s
$ kubectl get statefulset web
NAME      DESIRED   CURRENT   AGE
web       2         1         20s
$ kubectl get pods -w -l app=nginx
NAME      READY     STATUS    RESTARTS   AGE
web-0     0/1       Pending   0          0s
web-0     0/1       Pending   0         0s
web-0     0/1       ContainerCreating   0         0s
web-0     1/1       Running   0         19s
web-1     0/1       Pending   0         0s
web-1     0/1       Pending   0         0s
web-1     0/1       ContainerCreating   0         0s
web-1     1/1       Running   0         18s

StatefulSet 中的 Pod 拥有一个具有黏性的、独一无二的身份标志。这个标志基于 StatefulSet 控制器分配给每个 Pod 的唯一顺序索引。Pod 的名称的形式为<statefulset name>-<ordinal index>。webStatefulSet 拥有两个副本，所以它创建了两个 Pod：web-0和web-1

$ for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done
web-0
web-1
$ kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm
$ nslookup web-0.nginx
Server:    10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
Name:      web-0.nginx
Address 1: 10.244.1.6
$ nslookup web-1.nginx
Server:    10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
Name:      web-1.nginx
Address 1: 10.244.2.6

headless service 的 CNAME 指向 SRV 记录（记录每个 Running 和 Ready 状态的 Pod）。SRV 记录指向一个包含 Pod IP 地址的记录表项。

kubectl get pod -w -l app=nginx
kubectl delete pod -l app=nginx
pod "web-0" deleted
pod "web-1" deleted
等待 StatefulSet 重启它们，并且两个 Pod 都变成 Running 和 Ready 状态。
kubectl get pod -w -l app=nginx
NAME      READY     STATUS              RESTARTS   AGE
web-0     0/1       ContainerCreating   0          0s
NAME      READY     STATUS    RESTARTS   AGE
web-0     1/1       Running   0          2s
web-1     0/1       Pending   0         0s
web-1     0/1       Pending   0         0s
web-1     0/1       ContainerCreating   0         0s
web-1     1/1       Running   0         34s
使用 kubectl exec 和 kubectl run 查看 Pod 的主机名和集群内部的 DNS 表项。
for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done
web-0
web-1
kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh
nslookup web-0.nginx
Server:    10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
Name:      web-0.nginx
Address 1: 10.244.1.7
nslookup web-1.nginx
Server:    10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
Name:      web-1.nginx
Address 1: 10.244.2.8

Pod 的序号、主机名、SRV 条目和记录名称没有改变，但和 Pod 相关联的 IP 地址可能发生了改变。在本教程中使用的集群中它们就改变了。这就是为什么不要在其他应用中使用 StatefulSet 中的 Pod 的 IP 地址进行连接，这点很重要。


如果你需要查找并连接一个 StatefulSet 的活动成员，你应该查询 Headless Service 的 CNAME。和 CNAME 相关联的 SRV 记录只会包含 StatefulSet 中处于 Running 和 Ready 状态的 Pod。


如果你的应用已经实现了用于测试 liveness 和 readiness 的连接逻辑，你可以使用 Pod 的 SRV 记录（web-0.nginx.default.svc.cluster.local， web-1.nginx.default.svc.cluster.local）。因为他们是稳定的，并且当你的 Pod 的状态变为 Running 和 Ready 时，你的应用就能够发现它们的地址。

2. 扩容/缩容 StatefulSet

2.1 扩容

$ kubectl scale sts web --replicas=5   #扩展副本数为 5
$ kubectl get pods -w -l app=nginx
NAME      READY     STATUS    RESTARTS   AGE
web-0     1/1       Running   0          2h
web-1     1/1       Running   0          2h
NAME      READY     STATUS    RESTARTS   AGE
web-2     0/1       Pending   0          0s
web-2     0/1       Pending   0         0s
web-2     0/1       ContainerCreating   0         0s
web-2     1/1       Running   0         19s
web-3     0/1       Pending   0         0s
web-3     0/1       Pending   0         0s
web-3     0/1       ContainerCreating   0         0s
web-3     1/1       Running   0         18s
web-4     0/1       Pending   0         0s
web-4     0/1       Pending   0         0s
web-4     0/1       ContainerCreating   0         0s
web-4     1/1       Running   0         19s

2.2 缩容

$ kubectl patch sts web -p '{"spec":{"replicas":3}}'
$ kubectl get pods -w -l app=nginx
NAME      READY     STATUS              RESTARTS   AGE
web-0     1/1       Running             0          3h
web-1     1/1       Running             0          3h
web-2     1/1       Running             0          55s
web-3     1/1       Running             0          36s
web-4     0/1       ContainerCreating   0          18s
NAME      READY     STATUS    RESTARTS   AGE
web-4     1/1       Running   0          19s
web-4     1/1       Terminating   0         24s
web-4     1/1       Terminating   0         24s
web-3     1/1       Terminating   0         42s
web-3     1/1       Terminating   0         42s

3. 更新 StatefulSet

更新策略由 StatefulSet API Object 的spec.updateStrategy 字段决定。这个特性能够用来更新一个 StatefulSet 中的 Pod 的 container images，resource requests，以及 limits，labels 和 annotations。RollingUpdate滚动更新是 StatefulSets 默认策略。

3.1 Rolling Update 策略

$ kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}'
statefulset.apps/web patched
$ kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]'
statefulset.apps/web patched
$ kubectl get po -l app=nginx -w
NAME      READY     STATUS    RESTARTS   AGE
web-0     1/1       Running   0          7m
web-1     1/1       Running   0          7m
web-2     1/1       Running   0          8m
web-2     1/1       Terminating   0         8m
web-2     1/1       Terminating   0         8m
web-2     0/1       Terminating   0         8m
web-2     0/1       Terminating   0         8m
web-2     0/1       Terminating   0         8m
web-2     0/1       Terminating   0         8m
web-2     0/1       Pending   0         0s
web-2     0/1       Pending   0         0s
web-2     0/1       ContainerCreating   0         0s
web-2     1/1       Running   0         19s
web-1     1/1       Terminating   0         8m
web-1     0/1       Terminating   0         8m
web-1     0/1       Terminating   0         8m
web-1     0/1       Terminating   0         8m
web-1     0/1       Pending   0         0s
web-1     0/1       Pending   0         0s
web-1     0/1       ContainerCreating   0         0s
web-1     1/1       Running   0         6s
web-0     1/1       Terminating   0         7m
web-0     1/1       Terminating   0         7m
web-0     0/1       Terminating   0         7m
web-0     0/1       Terminating   0         7m
web-0     0/1       Terminating   0         7m
web-0     0/1       Terminating   0         7m
web-0     0/1       Pending   0         0s
web-0     0/1       Pending   0         0s
web-0     0/1       ContainerCreating   0         0s
web-0     1/1       Running   0         10s

获取 Pod 来查看他们的容器镜像。

$ for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
k8s.gcr.io/nginx-slim:0.8
k8s.gcr.io/nginx-slim:0.8
k8s.gcr.io/nginx-slim:0.8

kubectl rollout status sts/<name> 也可以查看 rolling update 的状态。

3.2 分段更新

你可以使用 RollingUpdate 更新策略的 partition 参数来分段更新一个 StatefulSet。分段的更新将会使 StatefulSet 中的其余所有 Pod 保持当前版本的同时仅允许改变 StatefulSet 的 .spec.template。


Patch web StatefulSet 来对 updateStrategy 字段添加一个分区。

$ kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}'
statefulset.apps/web patched

再次 Patch StatefulSet 来改变容器镜像。

$ kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]'
statefulset.apps/web patched

删除 StatefulSet 中的 Pod。

$ kubectl delete po web-2
pod "web-2" deleted

3.3 灰度发布

通过 patch 命令修改 StatefulSet 来减少分区。

$ kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}'
statefulset.apps/web patched
$ kubectl get po -lapp=nginx -w #等待 web-2 变成 Running 和 Ready。

4. 删除 StatefulSet

4.1 非级联删除

–cascade=false 参数给命令。这个参数告诉 Kubernetes 只删除 StatefulSet 而不要删除它的任何 Pod。

$ kubectl delete statefulset web --cascade=false
statefulset.apps "web" deleted
$ kubectl get pods -l app=nginx
NAME      READY     STATUS    RESTARTS   AGE
web-0     1/1       Running   0          6m
web-1     1/1       Running   0          7m
web-2     1/1       Running   0          5m
$ kubectl delete pod web-0
pod "web-0" deleted
$ kubectl get pods -l app=nginx
NAME      READY     STATUS    RESTARTS   AGE
web-1     1/1       Running   0          10m
web-2     1/1       Running   0          7m
$ kubectl apply -f web.yaml
statefulset.apps/web created
service/nginx unchanged
$ kubectl get pods -w -l app=nginx
NAME      READY     STATUS    RESTARTS   AGE
web-1     1/1       Running   0          16m
web-2     1/1       Running   0          2m
NAME      READY     STATUS    RESTARTS   AGE
web-0     0/1       Pending   0          0s
web-0     0/1       Pending   0         0s
web-0     0/1       ContainerCreating   0         0s
web-0     1/1       Running   0         18s
web-2     1/1       Terminating   0         3m
web-2     0/1       Terminating   0         3m
web-2     0/1       Terminating   0         3m
web-2     0/1       Terminating   0         3m

当重新创建 web StatefulSet 时，web-0被第一个重新启动。由于 web-1 已经处于 Running 和 Ready 状态，当 web-0 变成 Running 和 Ready 时，StatefulSet 会直接接收这个 Pod。由于你重新创建的 StatefulSet 的 replicas 等于 2，一旦 web-0 被重新创建并且 web-1 被认为已经处于 Running 和 Ready 状态时，web-2将会被终止。

4.2 级联删除

$ kubectl delete statefulset web
$ kubectl get pods -w -l app=nginx
NAME      READY     STATUS    RESTARTS   AGE
web-0     1/1       Running   0          11m
web-1     1/1       Running   0          27m
NAME      READY     STATUS        RESTARTS   AGE
web-0     1/1       Terminating   0          12m
web-1     1/1       Terminating   0         29m
web-0     0/1       Terminating   0         12m
web-0     0/1       Terminating   0         12m
web-0     0/1       Terminating   0         12m
web-1     0/1       Terminating   0         29m
web-1     0/1       Terminating   0         29m
web-1     0/1       Terminating   0         29m

虽然级联删除会删除 StatefulSet 和它的 Pod，但它并不会删除和 StatefulSet 关联的 Headless Service。你必须手动删除nginx Service。

$ kubectl delete service nginx
service "nginx" deleted

5. Pod 管理策略

5.1 Parallel Pod 管理策略

Parallel pod 管理策略告诉 StatefulSet 控制器并行的终止所有 Pod，在启动或终止另一个 Pod 前，不必等待这些 Pod 变成 Running 和 Ready 或者完全终止状态.

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  podManagementPolicy: "Parallel"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

执行：效果并行执行

kubectl get po -lapp=nginx -w
kubectl apply -f web-parallel.yaml
kubectl apply -f web-parallel.yaml
kubectl delete sts web
kubectl delete svc nginx

6. 示例

创建service

apiVersion: v1
kind: Service
metadata:
  labels:
    app: cassandra
  name: cassandra
spec:
  clusterIP: None
  ports:
  - port: 9042
  selector:
    app: cassandra
kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-service.yaml

创建stateful

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: cassandra
  labels:
    app: cassandra
spec:
  serviceName: cassandra
  replicas: 3
  selector:
    matchLabels:
      app: cassandra
  template:
    metadata:
      labels:
        app: cassandra
    spec:
      terminationGracePeriodSeconds: 1800
      containers:
      - name: cassandra
        image: gcr.io/google-samples/cassandra:v13
        imagePullPolicy: Always
        ports:
        - containerPort: 7000
          name: intra-node
        - containerPort: 7001
          name: tls-intra-node
        - containerPort: 7199
          name: jmx
        - containerPort: 9042
          name: cql
        resources:
          limits:
            cpu: "500m"
            memory: 1Gi
          requests:
            cpu: "500m"
            memory: 1Gi
        securityContext:
          capabilities:
            add:
              - IPC_LOCK
        lifecycle:
          preStop:
            exec:
              command: 
              - /bin/sh
              - -c
              - nodetool drain
        env:
          - name: MAX_HEAP_SIZE
            value: 512M
          - name: HEAP_NEWSIZE
            value: 100M
          - name: CASSANDRA_SEEDS
            value: "cassandra-0.cassandra.default.svc.cluster.local"
          - name: CASSANDRA_CLUSTER_NAME
            value: "K8Demo"
          - name: CASSANDRA_DC
            value: "DC1-K8Demo"
          - name: CASSANDRA_RACK
            value: "Rack1-K8Demo"
          - name: POD_IP
            valueFrom:
              fieldRef:
                fieldPath: status.podIP
        readinessProbe:
          exec:
            command:
            - /bin/bash
            - -c
            - /ready-probe.sh
          initialDelaySeconds: 15
          timeoutSeconds: 5
        # These volume mounts are persistent. They are like inline claims,
        # but not exactly because the names need to match exactly one of
        # the stateful pod volumes.
        volumeMounts:
        - name: cassandra-data
          mountPath: /cassandra_data
  # These are converted to volume claims by the controller
  # and mounted at the paths mentioned above.
  # do not use these in production until ssd GCEPersistentDisk or other ssd pd
  volumeClaimTemplates:
  - metadata:
      name: cassandra-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: fast
      resources:
        requests:
          storage: 1Gi
---
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fast
provisioner: k8s.io/minikube-hostpath
parameters:
  type: pd-ssd
# 创建 statefulset
kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml


参考资料：


StatefulSets 基础

使用 StatefulSets 部署 Cassandra

Kubernetes StatefulSet - Examples & Best Practices

宋净超 kubernetes StatefulSet

google cloud StatefulSet

详解 Kubernetes StatefulSet 实现原理


文章标签：
容器服务Kubernetes版
云解析DNS
Perl
容器
测试技术
应用服务中间件
NoSQL
Kubernetes
nginx
API
调度
关键词：
容器服务Kubernetes版应用
容器服务Kubernetes版statefulsets
容器服务Kubernetes版有状态
容器服务Kubernetes版状态
容器服务Kubernetes版有状态应用
相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用，部署一个新的应用用于新的发布，并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程，本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术，这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时，本课程也会向您介绍可以采取的工具、方法和可操作步骤，以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后，您将能够： 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
爱死亡机器人
目录
相关文章
阿里云计算巢-壬云
|
15天前
|
缓存 Kubernetes Docker
GitLab Runner 全面解析：Kubernetes 环境下的应用
GitLab Runner 是 GitLab CI/CD 的核心组件，负责执行由 `.gitlab-ci.yml` 定义的任务。它支持多种执行方式（如 Shell、Docker、Kubernetes），可在不同环境中运行作业。本文详细介绍了 GitLab Runner 的基本概念、功能特点及使用方法，重点探讨了流水线缓存（以 Python 项目为例）和构建镜像的应用，特别是在 Kubernetes 环境中的配置与优化。通过合理配置缓存和镜像构建，能够显著提升 CI/CD 流水线的效率和可靠性，助力开发团队实现持续集成与交付的目标。
阿里云计算巢-壬云
82 5
阿里云云原生
|
3天前
|
存储 监控 对象存储
ACK 容器监控存储全面更新：让您的应用运行更稳定、更透明
针对本地存储和 PVC 这两种容器存储使用方式，我们对 ACK 的容器存储监控功能进行了全新升级。此次更新完善了对集群中不同存储类型的监控能力，不仅对之前已有的监控大盘进行了优化，还针对不同的云存储类型，上线了全新的监控大盘，确保用户能够更好地理解和管理容器业务应用的存储资源。
阿里云云原生
49 16
阿里云基础设施.
|
8天前
|
存储 监控 对象存储
ACK容器监控存储全面更新：让您的应用运行更稳定、更透明
介绍升级之后的ACK容器监控体系，包括各大盘界面展示和概要介绍。
阿里云基础设施.
44 21
对你痴情
|
1月前
|
人工智能 Kubernetes 安全
赋能加速AI应用交付，F5 BIG-IP Next for Kubernetes方案解读
赋能加速AI应用交付，F5 BIG-IP Next for Kubernetes方案解读
对你痴情
70 13
弹性计算-百晓生
|
1月前
|
存储 Kubernetes 关系型数据库
阿里云ACK备份中心，K8s集群业务应用数据的一站式灾备方案
本文源自2024云栖大会苏雅诗的演讲，探讨了K8s集群业务为何需要灾备及其重要性。文中强调了集群与业务高可用配置对稳定性的重要性，并指出人为误操作等风险，建议实施周期性和特定情况下的灾备措施。针对容器化业务，提出了灾备的新特性与需求，包括工作负载为核心、云资源信息的备份，以及有状态应用的数据保护。介绍了ACK推出的备份中心解决方案，支持命名空间、标签、资源类型等维度的备份，并具备存储卷数据保护功能，能够满足GitOps流程企业的特定需求。此外，还详细描述了备份中心的使用流程、控制台展示、灾备难点及解决方案等内容，展示了备份中心如何有效应对K8s集群资源和存储卷数据的灾备挑战。
弹性计算-百晓生
80 5
阿里云基础设施.
|
2月前
|
存储 运维 Kubernetes
K8s业务迁移最佳实践: 灵活管理资源备份与调整策略，实现高效简便的应用恢复
在当今快速变化的云原生领域，Kubernetes（K8s）集群的运维面临着诸多挑战，其中灾备与业务迁移尤为关键。ACK备份中心支持丰富的资源调整策略，在数据恢复阶段即可自动适配目标集群环境，确保业务无缝重启。
阿里云基础设施.
105 4
光明顶阳顶天
|
2月前
|
监控 持续交付 Docker
Docker 容器化部署在微服务架构中的应用有哪些？
Docker 容器化部署在微服务架构中的应用有哪些？
光明顶阳顶天
96 2
光明顶阳顶天
|
2月前
|
监控 持续交付 Docker
Docker容器化部署在微服务架构中的应用
Docker容器化部署在微服务架构中的应用
光明顶阳顶天
196 3
IT行业工程师
|
2月前
|
Kubernetes 监控 安全
容器化技术：Docker与Kubernetes的实战应用
容器化技术：Docker与Kubernetes的实战应用
IT行业工程师
66 0
小周sir
|
2月前
|
Java Docker 微服务
利用Docker容器化部署Spring Boot应用
利用Docker容器化部署Spring Boot应用
小周sir
64 0

热门文章

最新文章

  • 1
    Kubernetes（k8s）和Docker Compose本质区别
  • 2
    OpenAI故障复盘 - 阿里云容器服务与可观测产品如何保障大规模K8s集群稳定性
  • 3
    ubuntu使用kubeadm搭建k8s集群
  • 4
    GitLab Runner 全面解析：Kubernetes 环境下的应用
  • 5
    入门级容器技术解析：Docker和K8s的区别与关系
  • 6
    容器服务Kubernetes场景下可观测体系生产级最佳实践
  • 7
    OpenAI 宕机思考丨Kubernetes 复杂度带来的服务发现系统的风险和应对措施
  • 8
    ACK One多集群网关：实现高效容灾方案
  • 9
    01/05 kubernetes-Pod生命周期
  • 10
    阿里云飞天企业版获【可信云·容器平台安全能力】先进级认证
  • 1
    Kubernetes学习-深入Pod篇(一) 创建Pod，Pod配置文件详解
    721
  • 2
    Kubernetes学习-集群搭建篇(三) Node配置完善和API概述
    97
  • 3
    Kubernetes学习-集群搭建篇(二) 部署Node服务，启动JNI网络插件
    364
  • 4
    Kubernetes学习-集群搭建篇(一) 搭建Master结点
    210
  • 5
    Kubernetes学习-核心概念篇(三) 核心概念和专业术语
    147
  • 6
    Kubernetes学习-核心概念篇(二) 集群架构与组件
    136
  • 7
    Kubernetes详解（九）——资源配置清单创建Pod实战
    143
  • 8
    Kubernetes详解（七）——Service对象部署和应用
    89
  • 9
    Kubernetes 集群的持续监控与性能优化策略
    148
  • 10
    Kubernetes详解（六）——Pod对象部署和应用
    151

    • 相关课程

    更多
  • 阿里云 EMR on ACK 实战
  • 阿里云K8S微服务部署案例
  • Kubernetes极速入门
  • Serverless 容器从入门到精通: - Serverless Kubernetes
  • Kubernetes云原生管理实践
  • Kubernetes入门

    • 相关电子书

    更多
  • ACK 云原生弹性方案—云原生时代的加速器
  • ACK集群类型选择最佳实践
  • 企业运维之云原生和Kubernetes 实战

    • 相关实验场景

    更多
  • 通过ACK Serverless搭建企业级网站应用
  • 基于ACK Serverless实现容器应用弹性伸缩
  • 在ACK Serverless中部署Stable Diffusion应用
  • 使用ACK Serverless容器化部署大语言模型FastChat
  • 通过EDAS实现K8s微服务应用的金丝雀发布
  • 基于ACK Serverless轻松部署企业级Stable Diffusion

    • 推荐镜像

    更多
  • kubernetes
  • ceph
  • CloudFoundry
    • 下一篇
    阿里云oss简介和如何对接使用