【云原生】k8s集群部署Rook+Ceph云原生存储

本文涉及的产品
对象存储 OSS,20GB 3个月
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 【云原生】k8s集群部署Rook+Ceph云原生存储

一、Rook介绍


Rook 官网地址:https://rook.io 是一个自管理的分布式存储编排系统,可以为Kubernetes提供便利的存储解决方案。

Rook本身并不提供存储,而是在kubernetes和存储系统之间提供适配层,简化存储系统的部署与维护工作。

目前,Rook支持的存储系统包括:Ceph、CockroachDB、Cassandra、EdgeFS、Minio、NFS。当然,Rook支持的最好的还是Ceph 和 NFS。

59cc5774796e4c6e93aa6bdcc203a513.png


二、Ceph介绍


Ceph 是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。Ceph 的统一体现在可以提供文件系统、块存储和对象存储,分布式体现在可以动态扩展。


Ceph支持三种存储:

  • 块存储(RDB):可以直接作为磁盘挂载
  • 文件系统(CephFS):提供POSIX兼容的网络文件系统CephFS,专注于高性能、大容量存储
  • 对象存储(RADOSGW):提供RESTful接口,也提供多种编程语言绑定。兼容S3(是AWS里的对象存储)、Swift(是openstack里的对象存储)


核心组件:

Ceph 主要有三个基本进程:


OSD

用于集群中所有数据与对象的存储,处理集群数据的复制、恢复、回填、再均衡,并向其他osd守护进程发送心跳,然后向 Monitor 提供一些监控信息。


Monitor

监控整个集群的状态,维护集群的 cluster MAP 二进制表,保证集群数据的一致性。


MDS (可选)

为 Ceph 文件系统提供元数据计算、缓存与同步。MDS 进程并不是必须的进程,只有需要使用 CephFS 时,才需要配置 MDS 节点。


三、部署Rook和Ceph


3.1 前置准备

通过rook安装ceph集群需要满足以下两个前提条件:

1.已部署好的Kubernetes集群 (✅)

2.osd节点需要有未格式化⽂件系统的磁盘(✅)

  1. 在master1节点下载rook到本地,使用1.8.8版本
git clone --single-branch --branch v1.8.8 https://github.com/rook/rook.git


  1. 给所有需要安装ceph的worker节点安装lvm2
yum install lvm2 -y
检查三台worker节点是否安装成功
[root@k8s-worker1 ~]# yum list installed | grep lvm2
lvm2.x86_64                        7:2.02.187-6.el7_9.5       @iflytekdc-updates
lvm2-libs.x86_64                   7:2.02.187-6.el7_9.5       @iflytekdc-updates


  1. 给worker节点打上标签,保证ceph只安装在这3台worker节点上
# master1节点上操作:
kubectl label node k8s-worker1 role=ceph-storage
kubectl label node k8s-worker2 role=ceph-storage
kubectl label node k8s-worker3 role=ceph-storage
修改完成后使用命令查看label属性
[root@k8s-master1 ~]# kubectl get nodes --show-labels 
NAME              STATUS   ROLES                  AGE     VERSION   LABELS
k8s-worker1   Ready    worker                 3d17h   v1.21.5   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-worker1,kubernetes.io/os=linux,node-role.kubernetes.io/worker=,role=ceph-storage
k8s-worker2   Ready    worker                 3d17h   v1.21.5   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-worker2,kubernetes.io/os=linux,node-role.kubernetes.io/worker=,role=ceph-storage
k8s-worker3   Ready    worker                 3d17h   v1.21.5   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-worker3,kubernetes.io/os=linux,node-role.kubernetes.io/worker=,role=ceph-storage


  1. 手动下载安装ceph所需镜像
    rook 中ceph依赖很多都是使用国外的镜像,下载很慢,而且经常出现400错误,所以建议直接手动下载。注意,以下脚本在所有节点都需要运行(master 和 worker)

创建可执行文件 ceph.sh,内容如下

image_list=(
  csi-node-driver-registrar:v2.5.0
  csi-attacher:v3.4.0
  csi-snapshotter:v5.0.1
  csi-resizer:v1.4.0
  csi-provisioner:v3.1.0
)
aliyuncs="registry.aliyuncs.com/it00021hot"
google_gcr="k8s.gcr.io/sig-storage"
for image in ${image_list[*]}
do
  docker image pull ${aliyuncs}/${image}
  docker image tag ${aliyuncs}/${image} ${google_gcr}/${image}
  docker image rm ${aliyuncs}/${image}
  echo "${aliyuncs}/${image} ${google_gcr}/${image} downloaded."
done


修改文件权限后执行拉取镜像
chmod +x ceph.sh
sh ceph.sh
查看镜像是否下载完成(master & node节点都需要下载)
[root@k8s-worker1 ~]# docker images | grep csi
k8s.gcr.io/sig-storage/csi-node-driver-registrar                   v2.5.0    cb03930a2bd4   4 months ago    19.6MB
k8s.gcr.io/sig-storage/csi-resizer                                 v1.4.0    551fd931edd5   4 months ago    55.5MB
k8s.gcr.io/sig-storage/csi-snapshotter                             v5.0.1    53ae5b88a338   4 months ago    55.2MB
k8s.gcr.io/sig-storage/csi-provisioner                             v3.1.0    c3dfb4b04796   4 months ago    57.7MB
k8s.gcr.io/sig-storage/csi-attacher                                v3.4.0    03e115718d25   5 months ago    54.8MB
  1. 修改ceph调度算法,通过节点亲和性让其运行在指定节点上,同时手动指定节点及磁盘
    还记得我们之前挂载磁盘的时候给ceph预留了一个空盘吧,如果没有空盘,可以新建一个,流程如下:

8690fd146d07433c86d6d2e19a9d2f9b.png

90528ef39c4d4b56a81a6b43bfe20a49.png

将新增的磁盘设置成独立模式(模拟公有云厂商提供的独立磁盘),然后启动K8S集群虚拟机,在工作节点上使用以下命令检查一下磁盘条件是否符合Ceph部署要求:

[root@node1 ~]# lsblk -f
NAME        FSTYPE      LABEL           UUID                                   MOUNTPOINT
sdb                                                                            
sr0         iso9660     CentOS 7 x86_64 2020-11-04-11-36-43-00                 
sda                                                                            
├─sda2      LVM2_member                 45inUD-qJ4O-Fq9E-L6KD-8eJV-mofD-BuJDq6 
│ └─centos_node1-root
            xfs                         704f37f0-ae59-4995-80ec-58cba66e023b   /
└─sda1      xfs                         67243cc8-c3fb-490f-b0da-cc439371d5e1   /boot

上述命令输出中 sdb 磁盘就是我们为工作节点新添加的裸设备(它的FSTYPE为空),我们可以把它分配给Ceph使用。

我们使用之前预留的空盘继续:

先通过lsblk查看盘符,可以看到vdb2是预留给ceph的

[root@k8s-worker2 ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0     11:0    1  478K  0 rom  
vda    253:0    0   50G  0 disk 
├─vda1 253:1    0    1G  0 part /boot
└─vda2 253:2    0   49G  0 part /
vdb    253:16   0  500G  0 disk 
├─vdb1 253:17   0  100G  0 part /var/lib/docker
└─vdb2 253:18   0  400G  0 part


然后修改ceph集群配置:

vim /root/rook/deploy/examples/cluster.yaml
• 1
#原始位置大概在138行 
# 第一处修改节点亲和性 ,设置为安装ceph的机器节点的标签(本文档worker节点标签role=ceph-storage)
placement:
    all:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: role
              operator: In
              values:
              - ceph-storage
#原始位置大概在215行起,
# Individual nodes and their config can be specified as well, but 'useAllNodes' above must be set to false. Then, only the named
 # nodes below will be used as storage resources.  Each node's 'name' field should match their 'kubernetes.io/hostname' label.
#  第二处修改
  storage: # cluster level storage configuration and selection
    useAllNodes: false
    useAllDevices: false
    config:
      journalSizeMB: "4096"
    nodes:
    - name: "k8s-worker1"
      devices:
        - name: "vdb2" # 可以通过lsblk查看磁盘信息
          config:
            storeType: bluestore
    - name: "k8s-worker2"
      devices: 
        - name: "vdb2" # 可以通过lsblk查看磁盘信息
          config:
            storeType: bluestore
    - name: "k8s-worker3"
      devices: 
        - name: "vdb2" # 可以通过lsblk查看磁盘信息
          config:
            storeType: bluestore


注意,name 不能够配置为IP,而应该是标签 kubernetes.io/hostname 的内容


6、修改operator.yaml,让CSI守护进程可以调度到主节点

默认情况下master节点是不允许调度的,但是ceph有些守护进程是需要调度到master去。这一步是为了解决后面出现的问题,如果此时不修改也可以在后面出现问题的时候再改。这些都是经验教训,网上的安装手册不会告诉你有这一步。

  1. 先查看一下master节点的污点设置
[root@k8s-master1 ~]# kubectl describe node k8s-master1 | grep Taints
Taints:             node-role.kubernetes.io/master:NoSchedule


然后修改rook operator的配置:

vim /root/rook/deploy/examples/operator.yaml
#原始位置在127行 原有注释去掉后,再往前缩进一格否则报错
CSI_PLUGIN_TOLERATIONS: |
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
    operator: Exists


3.2 部署Rook

ceph 相关镜像较大,创建集群过程中可能会存在镜像拉取失败问题,可以在worker节点提前下载。所需镜像:rook/ceph:v1.8.8 quay.io/ceph/ceph: v16.2.7 quay.io/cephcsi/cephcsi:v3.5.1


  1. 创建ceph所需要的资源
cd cluster/examples/kubernetes/ceph
kubectl create -f crds.yaml -f common.yaml -f operator.yaml


执行完成后等待容器启动,只有完全启动后才能执行进行下一步操作。

查看pod启动情况
[root@k8s-master1 examples]# kubectl get pod -n rook-ceph
rook-ceph-operator-84985d69d4-rncx4                      1/1     Running     0          117m


3.3 部署Ceph集群

需要先修改一下集群osd的资源限制,否则osd的内存使用率会无限增长(同样是经验教训)

cd /root/rook/deploy/examples
vim cluster.yaml
#在186行处加入资源限制,建议内存设置4G以上,同时需要注意yaml文件的格式
resources:
    osd:
      limits:
        cpu: "2"
        memory: "8000Mi"
      requests:
          cpu: "2"
          memory: "8000Mi"


修改保存后执行以下命令安装ceph集群

kubectl apply -f cluster.yaml


创建完成后,可以查看pod的状态

[root@k8s-master1 examples]# kubectl -n rook-ceph get pod
NAME                                                        READY   STATUS      RESTARTS   AGE
csi-cephfsplugin-gjmhv                                      3/3     Running     0          8m7s
csi-cephfsplugin-l2vz6                                      3/3     Running     0          8m7s
csi-cephfsplugin-provisioner-6f54f6c477-rnql9               6/6     Running     0          8m7s
csi-cephfsplugin-provisioner-6f54f6c477-vgvnj               6/6     Running     0          8m7s
csi-cephfsplugin-zplbg                                      3/3     Running     0          8m7s
csi-rbdplugin-54cgx                                         3/3     Running     0          8m7s
csi-rbdplugin-7795w                                         3/3     Running     0          8m7s
csi-rbdplugin-dtnqk                                         3/3     Running     0          8m7s
csi-rbdplugin-provisioner-6d765b47d5-g2lzc                  6/6     Running     0          8m7s
csi-rbdplugin-provisioner-6d765b47d5-klk9n                  6/6     Running     0          8m7s
rook-ceph-crashcollector-k8s-worker1-7598585c9b-49czg   1/1     Running     0          5m23s
rook-ceph-crashcollector-k8s-worker2-675d7c66f-lzw4n    1/1     Running     0          5m11s
rook-ceph-crashcollector-k8s-worker3-656f47985d-k4h96   1/1     Running     0          5m35s
rook-ceph-mgr-a-c9bf8bb54-kvgbw                             1/1     Running     0          5m40s
rook-ceph-mon-a-55b778d66d-dl8h6                            1/1     Running     0          8m1s
rook-ceph-mon-b-65f6d54689-zxblk                            1/1     Running     0          7m26s
rook-ceph-mon-c-dc947478f-2jt2r                             1/1     Running     0          5m53s
rook-ceph-operator-84985d69d4-z5bkq                         1/1     Running     0          18h
rook-ceph-osd-0-d77bf645f-mk9j7                             1/1     Running     0          5m12s
rook-ceph-osd-1-b7d7c47d-2kz5p                              1/1     Running     0          5m11s
rook-ceph-osd-2-78fbd4bdc7-zbjsz                            1/1     Running     0          5m11s
rook-ceph-osd-prepare-k8s-worker1-hzq7l                 0/1     Completed   0          5m19s
rook-ceph-osd-prepare-k8s-worker2-8pqlk                 0/1     Completed   0          5m19s
rook-ceph-osd-prepare-k8s-worker3-kb2q9                 0/1     Completed   0          5m19s


以上是所有组件的 pod 完成后的状态,以rook-ceph-osd-prepare 开头的 pod 用于自动感知集群新挂载硬盘,只不过我们前面手动指定了节点,所以这个不起作用。osd-0、osd-1、osd-2容器必须是存在且正常的,如果上述pod均正常运行成功,则视为集群安装成功。


3.4 部署ceph dashboard

Ceph Dashboard 是一个内置的基于 Web 的管理和监视应用程序,它是开源 Ceph 发行版的一部分。通过 Dashboard 可以获取 Ceph 集群的各种基本状态信息。

默认的 ceph 已经安装的 ceph-dashboard,其 SVC 地址是 service clusterIP,并不能被外部访问,需要创建 service 服务。

kubectl apply -f dashboard-external-https.yaml


创建NodePort类型就可以被外部访问了

[root@k8s-master1 ~]# kubectl get svc -n rook-ceph|grep dashboard
rook-ceph-mgr-dashboard                  ClusterIP   109.233.40.229   <none>        8443/TCP            8m28s
rook-ceph-mgr-dashboard-external-https   NodePort    109.233.34.181   <none>        8443:32234/TCP      29s


浏览器访问(master1-ip换成自己的集群ip):https://master1-ip:32234/

用户名默认是admin,至于密码可以通过以下代码获取:

kubectl -n rook-ceph get secret rook-ceph-dashboard-password -o jsonpath="{['data']['password']}"|base64 --decode && echo

2532b9a292994daf93ce7cdf65db7c77.png

99f3829f210a489a86197ed23751ef35.png


四、部署Rook工具箱


Rook 工具箱是一个包含用于 Rook 调试和测试的常用工具的容器,安装很简单。

cd /root/rook/deploy/examples
kubectl apply -f toolbox.yaml -n rook-ceph


待容器Running后,即可执行相关命令:

[root@k8s-master1 ~]# kubectl get po -n rook-ceph | grep tools
rook-ceph-tools-775f4f4468-dcg4x                            1/1     Running     0          2m12s
[root@k8s-master1 ~]# kubectl -n rook-ceph exec -it $(kubectl -n rook-ceph get pod -l "app=rook-ceph-tools" -o jsonpath='{.items[0].metadata.name}') -- bash
[rook@rook-ceph-tools-775f4f4468-dcg4x /]$ ceph -s
  cluster:
    id:     cea16e6d-ef51-4cfd-aa15-3a0e13075071
    health: HEALTH_OK
  services:
    mon: 3 daemons, quorum a,b,c (age 28m)
    mgr: a(active, since 27m)
    osd: 3 osds: 3 up (since 28m), 3 in (since 28m)
  data:
    pools:   0 pools, 0 pgs
    objects: 0 objects, 0 B
    usage:   15 MiB used, 1.2 TiB / 1.2 TiB avail
    pgs:
[rook@rook-ceph-tools-775f4f4468-dcg4x /]$ ceph osd status
ID  HOST              USED  AVAIL  WR OPS  WR DATA  RD OPS  RD DATA  STATE
 0  dev-k8s-worker3  4976k   399G      0        0       0        0   exists,up
 1  dev-k8s-worker2  4976k   399G      0        0       0        0   exists,up
 2  dev-k8s-worker1  4976k   399G      0        0       0        0   exists,up


工具箱相关查询命令:

ceph status
ceph osd status
ceph df
rados df


五、部署RBD StorageClass


Ceph 可以同时提供对象存储 RADOSGW、块存储 RBD、文件系统存储 Ceph FS。RBD 即 RADOS Block Device 的简称,RBD 块存储是最稳定且最常用的存储类型。RBD 块设备类似磁盘可以被挂载。RBD 块设备具有快照、多副本、克隆和一致性等特性,数据以条带化的方式存储在 Ceph 集群的多个 OSD 中。注意:RBD只支持ReadWriteOnce存储类型


  1. 创建 StorageClass
cd /root/rook/deploy/examples/csi/rbd
kubectl  apply -f storageclass.yaml


  1. 校验pool安装情况
[root@k8s-master1 ~]# kubectl -n rook-ceph exec -it $(kubectl -n rook-ceph get pod -l "app=rook-ceph-tools" -o jsonpath='{.items[0].metadata.name}') -- bash
[root@rook-ceph-tools-775f4f4468-dcg4x /]# ceph osd lspools
1 device_health_metrics
2 replicapool


  1. 查看StorageClass
[root@k8s-master1 rbd]# kubectl get sc
NAME              PROVISIONER                  RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
rook-ceph-block   rook-ceph.rbd.csi.ceph.com   Delete          Immediate           true                   43s


  1. 将Ceph设置为默认存储卷
[root@k8s-master1 ~]# kubectl patch storageclass rook-ceph-block -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'


修改完成后再查看StorageClass状态(有个default标识)

[root@k8s-master1 rbd]# kubectl get sc  
NAME                        PROVISIONER                  RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE  
rook-ceph-block (default)   rook-ceph.rbd.csi.ceph.com   Delete          Immediate           true                   108s


通过上面的步骤我们已经给Kubernetes集群安装了Ceph存储,至此我们的高可用集群就已经搭建完毕,甚至可以直接在生产环境使用了。同时也可以看到使用Rook安装Ceph还是很简单的,只需要执行对应的yaml文件即可。


不过要注意的是我们目前给集群安装的StorageClass是基于RBD的块存储,只支持ReadWriteOnce存储类型,如果你要使用ReadWriteMany存储类型,还需要安装CephFs存储。

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
19小时前
|
Kubernetes Cloud Native 微服务
企业级容器部署实战:基于ACK与ALB灵活构建云原生应用架构
这篇内容概述了云原生架构的优势,特别是通过阿里云容器服务Kubernetes版(ACK)和应用负载均衡器(ALB)实现的解决方案。它强调了ACK相对于自建Kubernetes的便利性,包括优化的云服务集成、自动化管理和更强的生态系统支持。文章提供了部署云原生应用的步骤,包括一键部署和手动部署的流程,并指出手动部署更适合有技术背景的用户。作者建议在预算允许的情况下使用ACK,因为它能提供高效、便捷的管理体验。同时,文章也提出了对文档改进的建议,如添加更多技术细节和解释,以帮助用户更好地理解和实施解决方案。最后,展望了ACK未来在智能化、安全性与边缘计算等方面的潜在发展。水文一篇,太忙了,见谅!
|
4天前
|
存储 弹性计算 运维
阿里云容器服务Kubernetes版(ACK)部署与管理体验评测
阿里云容器服务Kubernetes版(ACK)是一个功能全面的托管Kubernetes服务,它为企业提供了快速、灵活的云上应用管理能力。
67 1
|
5天前
|
存储 关系型数据库 分布式数据库
PolarDB,阿里云的云原生分布式数据库,以其存储计算分离架构为核心,解决传统数据库的扩展性问题
【7月更文挑战第3天】PolarDB,阿里云的云原生分布式数据库,以其存储计算分离架构为核心,解决传统数据库的扩展性问题。此架构让存储层专注数据可靠性,计算层专注处理SQL,提升性能并降低运维复杂度。通过RDMA加速通信,多副本确保高可用性。资源可独立扩展,便于成本控制。动态添加计算节点以应对流量高峰,展示了其灵活性。PolarDB的开源促进了数据库技术的持续创新和发展。
23 2
|
5天前
|
Prometheus Kubernetes Cloud Native
云原生周刊:Argo Rollouts 支持 Kubernetes Gateway API 1.0 | 2024.7.1
探索开源世界:Kubetools的推荐系统[Krs](https://github.com/kubetoolsca/krs)助力K8s优化,追踪K8s组件清单,指引IAC集成。阅读建议: Prometheus与Thanos的进化故事,Adidas容器平台管理经验,K8s请求实现详解。关注云原生:Argo Rollouts支持Gateway API 1.0,Kubewarden v1.14强化策略与镜像安全。
|
8天前
|
消息中间件 Kubernetes Android开发
消息队列 MQ产品使用合集之如何在kubernetes环境里面部署
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
10天前
|
前端开发 Devops 测试技术
阿里云云效产品使用问题之更换所部署的环境关联的ACK集群该如何实现
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
11天前
|
Kubernetes 应用服务中间件 nginx
K8s高可用集群二进制部署-V1.20
2.4 部署Etcd集群 以下在节点1上操作,为简化操作,待会将节点1生成的所有文件拷贝到节点2和节点3. 1. 创建工作目录并解压二进制包 mkdir /opt/etcd/{bin,cfg,ssl} -p tar zxvf etcd-v3.4.9-linux-amd64.tar.gz mv etcd-v3.4.9-linux-amd64/{etcd,etcdctl} /opt/etcd/bin/
|
存储 运维 Kubernetes
阿里云数字新基建系列:云原生操作系统Kubernetes-第1章(4)
阿里云数字新基建系列包括5本书,题材涉及Kubernetes、混合云架构、云数据库、CDN原理与流媒体技术、云服务器运维(Windows),囊括了领先的云技术知识与阿里云技术团队独到的实践经验,是国内IT技术图书中又一套重磅作品! 本书是阿里云容器服务产品线上实践的技术沉淀,主要包括理论篇和实践篇两部分内容。理论篇注重理论介绍,核心是Kubernetes on Cloud,即着重介绍Kubernetes和阿里云产品的结合。实践篇是疑难问题的诊断案例,希望通过案例来和读者分享Kubernetes深度问题诊断......
阿里云数字新基建系列:云原生操作系统Kubernetes-第1章(4)
|
运维 Kubernetes Cloud Native
阿里云数字新基建系列:云原生操作系统Kubernetes-第1章(3)
阿里云数字新基建系列包括5本书,题材涉及Kubernetes、混合云架构、云数据库、CDN原理与流媒体技术、云服务器运维(Windows),囊括了领先的云技术知识与阿里云技术团队独到的实践经验,是国内IT技术图书中又一套重磅作品! 本书是阿里云容器服务产品线上实践的技术沉淀,主要包括理论篇和实践篇两部分内容。理论篇注重理论介绍,核心是Kubernetes on Cloud,即着重介绍Kubernetes和阿里云产品的结合。实践篇是疑难问题的诊断案例,希望通过案例来和读者分享Kubernetes深度问题诊断......
阿里云数字新基建系列:云原生操作系统Kubernetes-第1章(3)
|
存储 弹性计算 Kubernetes
阿里云数字新基建系列:云原生操作系统Kubernetes-第1章(2)
阿里云数字新基建系列包括5本书,题材涉及Kubernetes、混合云架构、云数据库、CDN原理与流媒体技术、云服务器运维(Windows),囊括了领先的云技术知识与阿里云技术团队独到的实践经验,是国内IT技术图书中又一套重磅作品! 本书是阿里云容器服务产品线上实践的技术沉淀,主要包括理论篇和实践篇两部分内容。理论篇注重理论介绍,核心是Kubernetes on Cloud,即着重介绍Kubernetes和阿里云产品的结合。实践篇是疑难问题的诊断案例,希望通过案例来和读者分享Kubernetes深度问题诊断......
阿里云数字新基建系列:云原生操作系统Kubernetes-第1章(2)