迈入Docker、Kubernetes容器世界的大门
本文通过简单的示例，带领初学者快速迈入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.28Service
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.localdomainSecret
相较于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 rootStorage
我们将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-serverK8S集群使用存储
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 EOFPod生成后，检查发现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 pvSatefulset
如上面用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/htmlNamespace
细心的读者会在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平台了。
- 镜像格式为：<image_name>:<image_tag>，若不写image_tag，则默认为latest tag ↩
- 参考官方文档：Configure a Pod to Use a ConfigMap。 ↩
- 内容为key:value格式，且一个cm可包含多个 ↩
- statefulset名称的生成规则是固定的：<statefulset-name>-n ↩
- 存储必须支持动态提供，如glusterfs存储，要支持动态提供，必须配置heketi； ↩
- Openshift平台，其Project即为K8S的Namespace ↩
关注公众号 低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。
- 上一篇
循序渐进的手动安装k8s笔记-3
在上一篇笔记中，我们已经可以使用 k8s1.6 版本搭建一个基础的集群，在集群内部可以完成不同 node 之间的 pod 互通并且可以完成服务发现。但已经完成的这个集群仍然是通过不安全的 8080 端口进行的，并且除了最基本的 apiserver 和 controller-manager 之间以外，其他组件间通讯都没有认证措施。这一次，我准备在集群中加入 TLS 验证来加强集群的安全性，不过这次只加入认证并不考虑授权，同时加入 kubeconfig 配置文件的机制，将apiserver地址和一些客户端证书存放在 kubeconfig 配置文件中。再安装一个新的插件 Dashboard ，用于以web方式管理集群。 这次使用的 k8s 版本是比较新的 1.10.8 。第一个原因是已经决 定使用 kubeconfig 来进行配置所以旧版本不是必须的，另一个原因是在使用 tls 证书时 1.6.0 版本出现了一些 bug，所以就决定直接将 k8s 更换成比较新的版本。到目前为止 k8s 仍在快速迭代，所以建议在使用的时候选择新一些的版本。 参考资料： 《Kubernetes权威指南》 Kub...
- 下一篇
编排的艺术| K8S 中的容器编排和应用编排
众所周知，Kubernetes 是一个容器编排平台，它有非常丰富的原始的 API 来支持容器编排，但是对于用户来说更加关心的是一个应用的编排，包含多容器和服务的组合，管理它们之间的依赖关系，以及如何管理存储。 在这个领域，Kubernetes 用 Helm 的来管理和打包应用，但是 Helm 并不是十全十美的，在使用过程中我们发现它并不能完全满足我们的需求，所以在 Helm 的基础上，我们自己研发了一套编排组件…… 什么是编排？ 不知道大家有没仔细思考过编排到底是什么意思? 我查阅了 Wiki 百科，了解到我们常说的编排的英文单词为 “Orchestration”，它常被解释为: 本意:为管弦乐中的配器法，主要是研究各种管弦乐器的运用和配合方法， 通过各种乐器的不同音色，以便充分表现乐曲的内容和风格。 计算机领域:引申为描述复杂计算机系统、中间件 (middleware) 和业务的自动化的安排、协调和管理。 有趣的是 “Orchestration” 的标准翻译应该为“编配”，而“编排”则是 另外一个单词 “Choreography”，为了方便大家理解， 符合平时的习惯，我们还是使用编排...
相关文章
文章评论
共有0条评论来说两句吧...
微信收款码
支付宝收款码