AI 助理
备案控制台
开发者社区 云原生 容器服务 文章 正文

迈入Docker、Kubernetes容器世界的大门

2018-12-17 1855
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
容器镜像服务 ACR，镜像仓库100个 不限时长
简介： 本文通过简单的示例，带领初学者快速迈入Docker、Kubernetes（K8S）容器世界的大门。假设，你已拥有一个K8S集群，否则，可通过minikube或minishift快速搭建一实验环境。 Docker Docker与K8S ​ Docker本质上是一种虚拟化技术，类似于KVM、XEN、VMWARE，但其更轻量化，且将Docker部署在Linux环境时，其依赖于Linux容器技术（LXC）。

本文通过简单的示例，带领初学者快速迈入Docker、Kubernetes（K8S）容器世界 的大门。假设，你已拥有一个K8S集群，否则，可通过minikube或minishift快速搭建一实验环境。

Docker

Docker与K8S

​ Docker本质上是一种虚拟化技术，类似于KVM、XEN、VMWARE，但其更轻量化，且将Docker部署在Linux环境时，其依赖于Linux容器技术（LXC）。Docker较传统KVM等虚拟化技术的一个区别是无内核，即多个Docker虚拟机共享宿主机内核，简而言之，可把Docker看作是无内核的虚拟机，每Docker虚拟机有自己的软件环境，相互独立。

​ K8S与Docker之间的关系，如同Openstack之于KVM、VSphere之于VMWARE。K8S是容器集群管理系统，底层容器虚拟化可使用Docker技术，应用人员无需与底层Docker节点直接打交道，通过K8S统筹管理即可。

Docker基础

​ 如下所示，运行docker run -it --name test-docker busybox /bin/sh命令，观察其输出，可发现docker先在本地查找名为busybox的镜像（Image）1，若本地无镜像，则从docker.io官方镜像库（Registry）下载镜像后保存到本地，接着以此镜像构建一个名为test-docker的虚拟机，其Docker官方术语命名为容器（Container）。

# docker run -it --name test-docker busybox /bin/sh
Unable to find image 'busybox:latest' locally
Trying to pull repository docker.io/library/busybox ... 
latest: Pulling from docker.io/library/busybox
f70adabe43c0: Pull complete 
Digest: sha256:186694df7e479d2b8bf075d9e1b1d7a884c6de60470006d572350573bfa6dcd2
/ #

​ Docker较传统KVM、VMware虚拟机更轻量，如下所示，test-docker容器不会运行额外的系统与内核进程，其仅运行docker run命令提供的/bin/sh进程：

/ # ps -ef
PID USER TIME COMMAND
 1 root 0:00 /bin/sh
 7 root 0:00 ps -ef

​ 如在Openstack中创建虚拟机，首先需在Glance镜像库中存储虚拟机镜像，而后才能选择镜像以创建虚拟机。Docker同理，且官方提供一共享的镜像仓库（Registry），其中存储了各式各样的镜像（Image）。如本例用busybox镜像创建容器，其镜像被拉（pull）到了本地，可执行如下命令检查发现其仅1MB左右，相当轻量。

# docker images|grep busybox
docker.io/busybox latest 8ac48589692a 5 weeks ago 1.146 MB

​ 通过本节，我们了解了3个Docker基本要素：镜像仓库（Registry）中存储了镜像（Image），而镜像（Image）包含了程序运行所需的软件环境，当部署容器（Container）时，镜像（Image）通过网络被拉取到Doker主机（Node）。

Kubernetes

​ K8S是Google开源容器集群管理系统，其源于Google内部管理系统Borg，以下将通过一个个简单连贯的示例，带领初学者熟悉K8S集群。

Pod

​ K8S以Pod为最小单位来调度并管理Docker容器（Container），其中1个Pod可含多个容器，且相同Pod里的容器共享本地网络，容器间可通过localhost地址互访，即容器如同部署在相同的主机上，而以Pod为最小单元来调度则表明：Pod内的容器被调度到相同的Docker节点上。

​ 如下所示，创建一名为myhttp的Pod，其包含一个使用httpd镜像部署的容器，容器名为myhttp：

# cat > /tmp/myhttpd.pod <<EOF
apiVersion: v1
kind: Pod
metadata:
 name: myhttp
 labels:
 app: myhttp
spec:
 containers:
 - name: myhttp
 image: httpd
EOF
% kubectl create -f /tmp/myhttpd.pod

​ 执行kubectl get pod命令观察Pod运行成功后，接着验证容器能提供web服务：

# kubectl get pod
NAME READY STATUS RESTARTS AGE
myhttp 1/1 Running 0 1h
# kubectl describe pod myhttp|grep IP
IP: 10.129.0.232
# curl 10.129.0.232
<html><body><h1>It works!</h1></body></html>

Deployment

​ 将应用直接以Pod形式部署很少见，主因是：Pod无法提供弹性伸缩，且节点故障时K8S无法将其调度到幸存节点上，缺少自愈能力。鉴于此，应用常使用“镜像（Rc）/部署（Deployment）”部署，且在K8S新版本中，官方推荐用Deployment替代Rc部署无状态（Stateless）应用。

​ 执行kubectl delete pod myhttp删除pod后，换成以Deployment部署：

# cat > myhttp.yaml <<EOF 
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 labels:
 app: myhttp
 name: myhttp
spec:
 replicas: 1
 selector:
 matchLabels:
 app: myhttp
 template:
 metadata:
 labels:
 app: myhttp
 spec:
 containers:
 - image: httpd
 name: myhttp
EOF
# kubectl create -f /tmp/myhttp.yaml

​ Deployment中的.spec.replicas表明部署多少个Pod，如本例当前仅含一Pod：

# kubectl get deploy,pod
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deploy/myhttp 1 1 1 1 2m

NAME READY STATUS RESTARTS AGE
po/myhttp-7bc6d8b87c-gzlkq 1/1 Running 0 2m

​ 执行kubectl delete pod <pod_name>删除Pod后，可发现deployment将自动重建pod，其将确保拥有.spec.replicas个pod数量，即意味着，当pod异常时，deployment具备自愈特性。

# kubectl delete pod myhttp-7bc6d8b87c-gzlkq # kubectl get pod -w
NAME READY STATUS RESTARTS AGE
myhttp-7bc6d8b87c-dhmtz 0/1 ContainerCreating 0 2s
myhttp-7bc6d8b87c-dhmtz 1/1 Running 0 8s
myhttp-7bc6d8b87c-gzlkq 1/1 Terminating 0 8m

​ 当需伸缩或扩展应用时，若以Pod形式部署，则需删除或创建Pod，而若使用Deployment部署，则我们仅需调整.spec.replicas，而后K8S镜像控制器将自动调整Pod数量。如下所示，扩展http应用为2服务：

# kubectl scale deploy/myhttp --replicas=2 # kubectl get pod -w
NAME READY STATUS RESTARTS AGE
myhttp-7bc6d8b87c-cj4g8 0/1 ContainerCreating 0 3s
myhttp-7bc6d8b87c-zsbcc 1/1 Running 0 8m
myhttp-7bc6d8b87c-cj4g8 1/1 Running 0 18s

# kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
myhttp 2 2 2 2 21m

​ 执行kubectl delete pod <pod_name>删除Pod后，可发现Pod名（即容器主机名）及IP是随机分配的，那么，我们该如何访问应用？

# kubectl get pod # kubectl describe pod myhttp-7bc6d8b87c-cj4g8|grep IP
IP: 10.129.3.28

Service

​ Service服务类似于传统的F5、A10等硬件负载均衡，但其在K8S中通过软件实现，且当伸缩应用时可实时跟踪后端Server，无需人为调整。

内部访问

我们将对上节部署的myhttp应用创建一个Service服务，但在此前，先创建一个Pod作为集群内部客户端以用于后续Service验证。因下面验证Svc将使用curl工具，而官方centos镜像包含此工具，故用此镜像创建Pod，且为保证Pod一直运行不退出，使用了command在前台执行了无限循环命令。

# kubectl create -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
 name: myclient
 labels:
 app: myclient
spec:
 containers:
 - name: myclient
 image: centos
 command: ['sh','-c','while true; do sleep 3600; done;']
EOF

​ 执行如下命令为myhttp应用创建一个myhttp-int的服务：

# kubectl expose deployment myhttp --port=8080 --target-port=80 --name=myhttp-int
service "myhttp-int" exposed

​ 上面命令等价于使用下面的Yaml文件手动创建Service：创建名为myhttp-int的服务，其8080端口指向后端服务的80端口，而后端服务是通过selector选择label（标签）为app:myhttp的Pod，观察myhttp Deployment，可发现.spec.template.metadata.labels定义的标签就是app:myhttp，故而，通过myhttp-int:8080即可访问myhttp服务。

apiVersion: v1 kind: Service metadata: labels: app: myhttp name: myhttp-int spec: clusterIP: ports: - port: 8080 protocol: TCP targetPort: 80 selector: app: myhttp sessionAffinity: None

​ 在测试容器中通过myhttp-int:8080访问Service，可发现将负载均衡到后端的两pod上：

# kubectl get pod
NAME READY STATUS RESTARTS AGE
myclient 1/1 Running 0 1h
myhttp-7bc6d8b87c-cj4g8 1/1 Running 0 1d
myhttp-7bc6d8b87c-zsbcc 1/1 Running 0 1d

# 重置web主页，输出每Pod名称以便后续观察 # kubectl exec myhttp-7bc6d8b87c-cj4g8 -it -- sh -c "hostname>htdocs/index.html" # kubectl exec myhttp-7bc6d8b87c-zsbcc -it -- sh -c "hostname>htdocs/index.html" # kubectl exec -it myclient -- curl myhttp-int:8080
myhttp-7bc6d8b87c-cj4g8
# kubectl exec -it myclient -- curl myhttp-int:8080
myhttp-7bc6d8b87c-zsbcc

​ 当伸缩Pod时，我们可通过如下命令观察到Service将动态跟踪后端（Endpoints）服务：

# kubectl get endpoints myhttp-int
NAME ENDPOINTS AGE
myhttp-int 10.129.0.237:80,10.129.3.28:80 1h

# kubectl scale deploy myhttp --replicas=3 # kubectl get endpoints myhttp-int
NAME ENDPOINTS AGE
myhttp-int 10.129.0.237:80,10.129.3.28:80,10.131.0.194:80 1h

外部访问

​ 若应用需向K8S集群外提供服务，则可创建类型为NodePort的Service，此时K8S集群上所有节点均监听nodePort指定的端口，故外部应用可通过集群中任一节点访问集群内部提供的服务。

# kubectl create -f - <<EOF 
apiVersion: v1
kind: Service
metadata:
 labels:
 app: myhttp
 name: myhttp-pub
spec:
 type: NodePort
 ports:
 - port: 8080
 nodePort: 30001
 protocol: TCP
 targetPort: 80
 selector:
 app: myhttp
 sessionAffinity: None
EOF

​ 执行如下命令检查服务，发现一个为ClusterIP类型，一个为NodePort类型，但两者均分配了ClusterIP地址：

# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
myhttp-int ClusterIP 172.30.37.43 <none> 8080/TCP 1h
myhttp-pub NodePort 172.30.6.69 <none> 8080:30001/TCP 3m

​ myhttp-pub服务通过nodePort打开了集群各节点的主机端口，此时可通过集群任何节点访问服务：

# curl 192.168.220.21:30001
myhttp-7bc6d8b87c-zsbcc
# curl 192.168.230.21:30001
myhttp-7bc6d8b87c-zsbcc
# curl 192.168.240.21:30001
myhttp-7bc6d8b87c-cj4g8

​ 通过NodePort类型的Service虽可将服务暴露到集群外部，但问题是：端口数量有限（限制为30000-32767）、节点故障后，通过此节点访问服务将失败。鉴于此原因，NodePort类型的Service不常用，而是换成使用Ingress的技术来暴露服务到集群外部，但为简单考虑，本文不再讲解Ingress。

Configmap

​ 当容器异常时，镜像控制器用Image重建Container，此时对容器的修改会丢失，故而，若需自定义httpd镜像的httpd.conf文件，我们不应直接登录各容器修改配置，而应考虑使用K8S提供的Configmap2技术，其作为中央存储配置库所创建的文件将Pod共享。

​ 如下所示，为简单考虑，我们随意创建一文件并挂载到Deployment中，修改Configmap，扩展Deployment，用此来讲解Configmap作用。

创建一名为my-config的cm3：

# kubectl create -f - <<EOF
apiVersion: v1
metadata:
 name: my-config
data:
 hosts: |
 127.0.0.1 localhost localhost.localdomain
 #::1 localhost localhost.localdomain
kind: ConfigMap
EOF

执行kubectl edit deploy myhttp修改Deployment，将cm挂载到/etc/myhosts目录中。完整Yaml文件如下（PS：添加volumeMounts与volume）：

apiVersion: extensions/v1beta1 kind: Deployment metadata: labels: app: myhttp name: myhttp spec: replicas: 1 selector: matchLabels: app: myhttp template: metadata: labels: app: myhttp spec: containers: - image: httpd name: myhttp volumeMounts: - name: config-hosts mountPath: /etc/myhosts volumes: - name: config-hosts configMap: name: my-config

​ 修改Deploy后，可发现Pod将自动重建，而后检查每Pod可发现目录中含有cm的hosts文件：

# kubectl get pod
NAME READY STATUS RESTARTS AGE
myhttp-774ffbb989-gz6bd 1/1 Running 0 11m
myhttp-774ffbb989-k8m4b 1/1 Running 0 11m
myhttp-774ffbb989-t74nk 1/1 Running 0 11m

# kubectl exec -it myhttp-774ffbb989-gz6bd -- ls /etc/myhosts
hosts
# kubectl exec -it myhttp-774ffbb989-gz6bd -- cat /etc/myhosts/hosts
127.0.0.1 localhost localhost.localdomain
#::1 localhost localhost.localdomain

修改cm，几分钟后，可发现pod中的配置被自动更新：

# kubectl edit cm my-config
...
data:
 hosts: |
 127.0.0.1 localhost localhost.localdomain
 ::1 localhost localhost.localdomain
...

# kubectl exec -it myhttp-774ffbb989-gz6bd -- cat /etc/myhosts/hosts
127.0.0.1 localhost localhost.localdomain
::1 localhost localhost.localdomain

扩展应用，继而检查新的Pod，发现其包含cm内容：

# kubectl scale deploy myhttp --replicas=4 # kubectl get pod
myhttp-774ffbb989-gz6bd 1/1 Running 0 15h
myhttp-774ffbb989-k8m4b 1/1 Running 0 15h
myhttp-774ffbb989-t74nk 1/1 Running 0 15h
myhttp-774ffbb989-z5d6h 1/1 Running 0 21s

# kubectl exec -it myhttp-774ffbb989-z5d6h -- cat /etc/myhosts/hosts
127.0.0.1 localhost localhost.localdomain
::1 localhost localhost.localdomain

Secret

​ 相较于Configmap用于保存明文，那么Secret则保存密文，如用户密码等铭感数据，可使用Secret加密保存。如下所示，我们创建一个Secret加密用户与密码，而后提供给容器使用。

Opaque的Secret数据是一个map类型，要求value是base64编码格式。加密用户与密码：

# echo -n root | base64
cm9vdA==
# echo -n Changeme | base64
Q2hhbmdlbWU=

创建名为userpwd-secret的Secret，其包含用户与密码：

# kubectl create -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
 name: userpwd-secret
type: Opaque
data:
 username: cm9vdA==
 password: Q2hhbmdlbWU=
EOF

更新deployment，将secret以volume方式挂载到容器中：

# kubectl edit deployment myhttp
...
spec:
...
 spec:
 containers:
 - image: httpd
 ...
 volumeMounts:
 - name: userpwd
 mountPath: /etc/mysecret
 ...
 volumes:
 - name: userpwd
 secret:
 secretName: userpwd-secret
...

登录容器可发现secret中的key被保存为文件，其内容为value，但在容器内已被正确解密：

# kubectl exec -it myhttp-64575c77c-kqdj9 -- ls -l /etc/mysecret
lrwxrwxrwx. 1 root root 15 May 17 07:01 password -> ..data/password
lrwxrwxrwx. 1 root root 15 May 17 07:01 username -> ..data/username

# kubectl exec -it myhttp-64575c77c-kqdj9 -- cat /etc/mysecret/username
root

Storage

​ 我们将web应用保存到外部存储中，而后挂载到Pod上，这样，无论pod是否重建亦或伸缩，我们发布的应用都不会丢失。

配置NFS存储

为简单考虑，本例采用NFS作为共享存储：

nfs服务器安装软件：

# yum install nfs-utils

配置共享目录：

# mkdir -p /exports/httpd # chmod 0777 /exports/* # chown nfsnobody:nfsnobody /exports/* # cat > /etc/exports.d/k8s.exports <<EOF
/exports/httpd *(rw,root_squash)
EOF

配置防火墙，放行nfs端口：

# firewall-cmd --add-port=2049/tcp # firewall-cmd --permanent --add-port=2049/tcp

配置Selinux以允许Docker写数据到nfs：

# getsebool -a|grep virt_use_nfs # setsebool -P virt_use_nfs=true

启动nfs服务：

# systemctl restart nfs-config # systemctl restart nfs-server # systemctl enable nfs-server

K8S集群使用存储

K8S集群每节点安装nfs客户端软件，并设置Selinux权限：

# yum install nfs-utils # setsebool -P virt_use_nfs=true

创建一类型为nfs的持久化卷：PersistentVolume（PV），其指向nfs后端存储：

# kubectl create -f - <<EOF
apiVersion: v1
kind: PersistentVolume
metadata:
 name: httpd
spec:
 accessModes:
 - ReadWriteMany
 capacity:
 storage: 1Gi
 nfs:
 path: /exports/httpd
 server: 192.168.240.11
 persistentVolumeReclaimPolicy: Retain
EOF

创建一持久化卷声明PersistentVolumeClaim（PVC）指向上一步创建的PV：

# kubectl create -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: httpd
spec:
 accessModes:
 - ReadWriteMany
 resources:
 requests:
 storage: 1Gi
 volumeName: httpd
EOF

检查可发现pvc/httpd绑定到pv/httpd：

# oc get pv,pvc
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM ... 
pv/httpd 1Gi RWX Retain Bound demo/httpd ...

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc/httpd Bound httpd 1Gi RWX 53s

重建deployment，添加volume与mount挂载点：

# kubectl delete deploy myhttp # kubectl create -f - <<EOF
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 labels:
 app: myhttp
 name: myhttp
spec:
 replicas: 3
 selector:
 matchLabels:
 app: myhttp
 template:
 metadata:
 labels:
 app: myhttp
 spec:
 containers:
 - image: httpd
 name: myhttp
 imagePullPolicy: IfNotPresent
 volumeMounts:
 - name: config-hosts
 mountPath: /etc/myhosts
 - name: userpwd
 mountPath: /etc/mysecret
 - name: httpd-htdocs
 mountPath: /usr/local/apache2/htdocs
 volumes:
 - name: config-hosts
 configMap:
 name: my-config
 - name: userpwd
 secret:
 secretName: userpwd-secret
 - name: httpd-htdocs
 persistentVolumeClaim:
 claimName: httpd
EOF

Pod生成后，检查发现nfs目录被挂载到容器内：

# kubectl get pod # kubectl exec -it myhttp-8699b7d498-dlzrm -- df -h
Filesystem Size Used Avail Use% Mounted on
...
192.168.240.11:/exports/httpd 37G 17G 21G 44% /usr/local/apache2/htdocs ...
# kubectl exec -it myhttp-8699b7d498-dlzrm -- ls htdocs # 当前目录为空

登录任何一个容器，将web应用发布到htdocs目录：

# kubectl exec -it myhttp-8699b7d498-dlzrm -- /bin/sh # echo "this is a test of pv" > htdocs/index.html # 容器内

而后，我们删除容器亦或扩展容器，均会发现容器中的htdocs包含所发布的应用：

# kubectl delete pod -l app=myhttp # 删除所有myhttp pod # kubectl get pod # 等待pod重建完毕 # kubectl exec -it myhttp-8699b7d498-6q8tv -- cat htdocs/index.html
this is a test of pv

Satefulset

​ 如上面用Deplyment创建的myhttp应用，其是无状态（stateless）的，主机名是随机动态分配的，且所有Pod可共享挂载相同的存储（volume），但如Kafaka、Zookeeper集群，其是有状态的，需要主机名确定为一，且各自挂载存储，鉴于此，K8S提供了Satefulset技术来满足此类应用需求。

​ 如下所示，我们使用nginx镜像创建一个有状态的集群，用此来讲解Statefulset用法。

不同于Deployment，我们必须先创建一个ClusterIP: None的Service服务：

# kubectl create -f - <<EOF
apiVersion: v1
kind: Service
metadata:
 name: web
 labels:
 app: nginx-web
spec:
 ports:
 - port: 80
 name: web
 clusterIP: None
 selector:
 app: nginx-web
EOF

此Service无ClusterIP，也即我们无法直接通过此Servcie访问后端服务。

# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
web ClusterIP None <none> 80/TCP 3s

创建名为nginx的有状态服务，镜像数为2，且注意ServiceName配置为上步创建的Svc：

# kubectl create -f - <<EOF
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
 name: nginx
spec:
 serviceName: web
 replicas: 2
 template:
 metadata:
 labels:
 app: nginx-web
 spec:
 containers:
 - name: nginx
 image: nginx
 ports:
 - containerPort: 80
 name: web
EOF

观察pod启动，可发现pod名称为nginx-n格式4，此名称是固定唯一的，且可发现pod是顺序启动的，即容器nginx-n在nginx-<n-1>后启动。

# kubectl get pod -w
NAME READY STATUS RESTARTS AGE
nginx-0 0/1 ContainerCreating 0 7s
nginx-0 1/1 Running 0 10s
nginx-1 0/1 Pending 0 0s
nginx-1 0/1 Pending 0 0s
nginx-1 0/1 ContainerCreating 0 1s
nginx-1 1/1 Running 0 13s

创建的service被statefulset用在dns上以跟踪pod名称：

# kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh # 如下操作均在刚创建的dns-test pod中进行： # nslookup web # 查找web服务，可发现后端有两pod
...

Name: web
Address 1: 10.129.0.248 nginx-0.web.demo.svc.cluster.local
Address 2: 10.131.0.200 nginx-1.web.demo.svc.cluster.local

# nslookup nginx-0.web # 验证pod名称对应的IP地址
...
Name: nginx-0.web.demo.svc.cluster.local
Address 1: 10.129.0.248 nginx-0.web.demo.svc.cluster.local

# nslookup nginx-1.web
...
Name: nginx-1.web.demo.svc.cluster.local
Address 1: 10.131.0.200 nginx-1.web.demo.svc.cluster.local

配置satefulset挂载volume：

# kubectl delete statefulset nginx # 为简单起见，删除以上创建的statefulset # kubectl create -f - <<EOF
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
 name: nginx
spec:
 serviceName: web
 replicas: 2
 template:
 metadata:
 labels:
 app: nginx-web
 spec:
 containers:
 - name: nginx
 image: nginx
 ports:
 - containerPort: 80
 name: web
 volumeMounts:
 - name: www
 mountPath: /usr/share/nginx/html
 volumeClaimTemplates:
 - metadata:
 name: www
 spec:
 accessModes: [ "ReadWriteOnce" ]
 storageClassName: glusterfs-raid0
 resources:
 requests:
 storage: 10Mi
EOF

​ 注意：在volumeClaimTemplates.spec中添加的storageClassName，其指定了名为glusterfs-raid0的存储，这样，当pod生成时，k8s会使用动态提供5创建PVC、PV并自动从存储池glusterfs-raid0中动态分配volume。当然，若使用Storage一节中配置的nfs存储，则此处需删除storageClassName，而后手动创建存储、pv、pvc。

检查：

# 如下卷是k8s使用动态提供自动从glusterfs创建的： # kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
www-nginx-0 Bound pvc-4a76e4a9... 1Gi RWO glusterfs-raid0 22h
www-nginx-1 Bound pvc-536e8980... 1Gi RWO glusterfs-raid0 22h

# kubectl get statefulset,pod
NAME DESIRED CURRENT AGE
statefulsets/nginx 2 2 22h

NAME READY STATUS RESTARTS AGE
po/nginx-0 1/1 Running 0 22h
po/nginx-1 1/1 Running 0 22h

# 两Pod挂载各自的卷： # kubectl exec -it nginx-0 -- df -h
Filesystem Size Used Avail Use% Mounted on 
192.168.220.21:vol_e6858... 1016M 33M 983M 4% /usr/share/nginx/html

# kubectl exec -it nginx-1 -- df -h
Filesystem Size Used Avail Use% Mounted on 
192.168.220.21:vol_c659cc... 1016M 33M 983M 4% /usr/share/nginx/html

Namespace

​ 细心的读者会在Storage一节中看到demo/httpd，此demo就是作者所使用的Namespace/Project6。如同Openstack云计算平台提供了多租户用途，其每租户可创建自己的Project（项目），K8S同样提供多租户功能，我们可创建不同的Namespace（命名空间），并将以上所示的Pod、Service、Configmap等限制在Namespace中。

​ 刚搭建的K8S集群，默认有如下两Namespace：

# kubectl get namespace
NAME DISPLAY NAME STATUS
default Active # 默认命名空间
kube-system Active # k8s自身使用的命名空间

​ 我们可执行如下命令创建命名空间：

# kubectl create namespace demo
namespace "demo" created

​ 而后，执行kubectl命令时可附带”-n <namespace>“参数。如下所示，查询Pod：

# kubectl get pod -n demo
NAME READY STATUS RESTARTS AGE
nginx-0 1/1 Running 0 23h
nginx-1 1/1 Running 0 23h

​ 最后，对于Openshift平台，我们可执行如下命令登录到Namespace中，这样，我们就无需每次附带“-n <namespace>”了。

# oc project demo # oc get pod
NAME READY STATUS RESTARTS AGE
nginx-0 1/1 Running 0 23h
nginx-1 1/1 Running 0 23h

结束语

​ 通过本文，我们学习了Docker、K8S核心知识，我相信读者应完全可以熟练使用K8S平台了。

  1. 镜像格式为：<image_name>:<image_tag>，若不写image_tag，则默认为latest tag ↩
  2. 参考官方文档：Configure a Pod to Use a ConfigMap。 ↩
  3. 内容为key:value格式，且一个cm可包含多个 ↩
  4. statefulset名称的生成规则是固定的：<statefulset-name>-n ↩
  5. 存储必须支持动态提供，如glusterfs存储，要支持动态提供，必须配置heketi； ↩
  6. Openshift平台，其Project即为K8S的Namespace ↩

文章标签：
容器服务Kubernetes版
云虚拟主机
容器
Perl
应用服务中间件
Web App开发
存储
关键词：
容器服务Kubernetes版容器
Docker容器
docker容器服务Kubernetes版
Docker Kubernetes
容器kubernetes
相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用，部署一个新的应用用于新的发布，并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程，本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术，这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时，本课程也会向您介绍可以采取的工具、方法和可操作步骤，以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后，您将能够： 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
店家小二
目录
相关文章
刘大猫.
|
4天前
|
监控 NoSQL 时序数据库
《docker高级篇（大厂进阶）：7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括：原生命令、是什么、compose容器编排，一套带走
《docker高级篇（大厂进阶）：7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括：原生命令、是什么、compose容器编排，一套带走
刘大猫.
121 77
我是快乐的嘟嘟
|
12天前
|
监控 Docker 容器
在Docker容器中运行打包好的应用程序
在Docker容器中运行打包好的应用程序
我是快乐的嘟嘟
102 64
弹性计算-百晓生
|
2天前
|
人工智能 运维 监控
阿里云ACK容器服务生产级可观测体系建设实践
本文整理自2024云栖大会冯诗淳（花名：行疾）的演讲，介绍了阿里云容器服务团队在生产级可观测体系建设方面的实践。冯诗淳详细阐述了容器化架构带来的挑战及解决方案，强调了可观测性对于构建稳健运维体系的重要性。文中提到，阿里云作为亚洲唯一蝉联全球领导者的容器管理平台，其可观测能力在多项关键评测中表现优异，支持AI、容器网络、存储等多个场景的高级容器可观测能力。此外，还介绍了阿里云容器服务在多云管理、成本优化等方面的最新进展，以及即将推出的ACK AI助手2.0，旨在通过智能引擎和专家诊断经验，简化异常数据查找，缩短故障响应时间。
弹性计算-百晓生
28 8
阿里云ACK容器服务生产级可观测体系建设实践
弹性计算-百晓生
|
2天前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
阿里云容器服务ACK提供强大的产品能力，支持弹性、调度、可观测、成本治理和安全合规。针对拥有IDC或三方资源的企业，ACK One分布式云容器平台能够有效解决资源管理、多云多集群管理及边缘计算等挑战，实现云上云下统一管理，提升业务效率与稳定性。
弹性计算-百晓生
21 7
蓝易云
|
5天前
|
数据建模 应用服务中间件 nginx
docker替换宿主与容器的映射端口和文件路径
通过正确配置 Docker 的端口和文件路径映射，可以有效地管理容器化应用程序，确保其高效运行和数据持久性。在生产环境中，动态替换映射配置有助于灵活应对各种需求变化。以上方法和步骤提供了一种可靠且易于操作的方案，帮助您轻松管理 Docker 容器的端口和路径映射。
蓝易云
32 3
龙大吉
|
12天前
|
存储 缓存 监控
Docker容器性能调优的关键技巧，涵盖CPU、内存、网络及磁盘I/O的优化策略，结合实战案例，旨在帮助读者有效提升Docker容器的性能与稳定性。
本文介绍了Docker容器性能调优的关键技巧，涵盖CPU、内存、网络及磁盘I/O的优化策略，结合实战案例，旨在帮助读者有效提升Docker容器的性能与稳定性。
龙大吉
42 7
龙大吉
|
12天前
|
负载均衡 网络协议 算法
Docker容器环境中服务发现与负载均衡的技术与方法，涵盖环境变量、DNS、集中式服务发现系统等方式
本文探讨了Docker容器环境中服务发现与负载均衡的技术与方法，涵盖环境变量、DNS、集中式服务发现系统等方式，以及软件负载均衡器、云服务负载均衡、容器编排工具等实现手段，强调两者结合的重要性及面临挑战的应对措施。
龙大吉
33 3
众所周知
|
12天前
|
存储 安全 数据安全/隐私保护
Docker 容器化应用管理更加高效，但数据安全和业务连续性成为关键。
在数字化时代，Docker 容器化应用管理更加高效，但数据安全和业务连续性成为关键。本文探讨了 Docker 应用的备份与恢复策略，涵盖备份的重要性、内容、方法及常见工具，制定备份策略，恢复流程及注意事项，并通过案例分析和未来趋势展望，强调备份与恢复在保障应用安全中的重要性。
众所周知
22 2
龙大吉
|
12天前
|
存储 安全 数据中心
Docker 容器凭借轻量级和高效的特性，成为应用部署的重要工具
Docker 容器凭借轻量级和高效的特性，成为应用部署的重要工具。本文探讨了 Docker 如何通过 Namespace 和 Cgroups 实现 CPU、内存、网络和存储资源的隔离，提高系统安全性和资源利用率，以及面临的挑战和应对策略。
龙大吉
29 1
阿里云基础设施.
|
1天前
|
人工智能 弹性计算 运维
ACK Edge与IDC：高效容器网络通信新突破
本文介绍如何基于ACK Edge以及高效的容器网络插件管理IDC进行容器化。
阿里云基础设施.
17 4
云原生

容器服务

热门文章

最新文章

  • 1
    Docker 镜像加速器
  • 2
    Docker CE 镜像源站
  • 3
    Minikube - Kubernetes本地实验环境
  • 4
    Docker的Windows容器初体验
  • 5
    Docker学习路线图 (持续更新中)
  • 6
    当 Kubernetes 遇到阿里云
  • 7
    谈谈 Docker Volume 之权限管理（一）
  • 8
    容器镜像服务 Docker镜像的基本使用
  • 9
    理解Docker容器的进程管理
  • 10
    在阿里云容器服务上开发基于Docker的Spring Cloud微服务应用
  • 1
    canal-starter 监听解析 storeValue 不一样，同样的sql 一个在mybatis执行 一个在数据库操作，导致解析不出正确对象
    35
  • 2
    【Docker最新版教程】一文带你快速入门Docker常见用法，实现容器编排和自动化部署上线项目
    140
  • 3
    【最新版正确姿势】Docker安装教程（简单几步即可完成）
    684
  • 4
    ​​国内 5 个最佳的控制面板，可轻松管理服务器
    109
  • 5
    【赵渝强老师】K8s的有状态控制器StatefulSet
    49
  • 6
    【赵渝强老师】K8s中Deployment控制器与StatefulSet控制器的区别
    39
  • 7
    【赵渝强老师】K8s的Job控制器多工作队列的并行方式
    33
  • 8
    【赵渝强老师】K8s的周期性任务控制器CronJob
    41
  • 9
    【赵渝强老师】K8s中Job控制器单工作队列的串行方式
    33
  • 10
    【赵渝强老师】K8s中的Deployment控制器
    31

    • 相关产品

  • 容器服务Kubernetes版
    文档详情 产品详情

    • 相关课程

    更多
  • 基于Docker与Jenkins实现自动化部署
  • 容器安全与Palo Alto Networks解决方案
  • Docker 快速入门
  • Docker完全自学手册图文教程
  • AI开发者的Docker实践
  • Docker 入门

    • 相关电子书

    更多
  • 阿里云文件存储 NAS 在容器场景的最佳实践
  • 何种数据存储才能助力容器计算
  • 《容器网络文件系统CNFS》

    • 相关实验场景

    更多
  • 部署并使用Docker（AlibabaCloud Linux 3）
  • 通过容器镜像仓库与容器服务快速部署spring-hello应用
  • Docker Compose部署案例
  • Docker Compose入门
  • 容器中的volume卷
  • 容器的文件系统挂载

    • 推荐镜像

    更多
  • kubernetes
  • docker-ce
  • docker-toolbox
    • 下一篇
    阿里云对象存储OSS收费标准：存储、流量和请求等多个计费项详解