标签：kubernetes

1、如何获取rpm包，及制作kubernetes镜像

1.1 官方yum源，有翻墙能力的 请使用

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
       https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

1.2 自行编译生成相关rpm包

下载源码包
git clone 
https://github.com/kubernetes/release
 kubeadm
cd kubeadm/rpm
sh docker-build.sh

结果在 rpm/output/x86_64/yum/

kubectl-1.8.2-0.x86_64.rpm
kubelet-1.8.2-0.x86_64.rpm
kubeadm-1.8.2-0.x86_64.rpm
kubernetes-cni-0.5.1-0.x86_64.rpm

期间会生成一个docker image叫kubelet-rpm-builder，也需要翻墙
我已上传自己私有仓

https://hub.docker.com/r/foxchan/kubelet-rpm-builder/

注意：如果提前下载好kubelet-rpm-builder,需要修改rpm目录下的docker-build.sh 和Dockerfile

Dockerfile修改如下：

FROM foxchan/kubelet-rpm-builder
USER root
ADD entry.sh /root/
COPY ./ /root/rpmbuild/SPECS
ENTRYPOINT ["/root/entry.sh"]

docker-build.sh

#!/bin/sh
set -e
echo "Cleaning output directory..."
sudo rm -rf output/*
mkdir -p output
docker run -ti --rm -v $PWD/output/:/root/rpmbuild/RPMS/ kubelet-rpm-builder $1
sudo chown -R $USER $PWD/output
echo
echo "----------------------------------------"
echo
echo "RPMs written to: "
ls $PWD/output/*/
echo
echo "Yum repodata written to: "
ls $PWD/output/*/repodata/

2、利用github，创建kubernetes镜像

2.1 Dockerfile上传到github

github上新建一个工程，https://github.com/foxchenlei/docker-library

然后在工程中新增： ./kube-apiserver-amd64/Dockerfile，Dockerfile内容为：

FROM gcr.io/google_containers/kube-apiserver-amd64:v1.8.2 
MAINTAINER FoxChan

2.2 Docker Hub上创建Automated build

到docker hub上，Create -> Create Automated Build，新增一个Github类型的自动编译，选择docker-library项目；修改Repository的Name为kube-apiserver-amd64，简单填下描述，这样就创建了一个Automated Build。

进到Repository kube-apiserver-amd64，Build Setting中填写Dockerfile Location为kube-apiserver-amd64，修改Docker Tag Name为1.8.2，Save Change and Trigger；然后点Build Details，可以看到build的过程，状态切为Success就可以了。

2.3 剩下的，就是重复上面的操作，把你需要的镜像全部构建到hub.docker.com,以后需要的时候 就pull下来

本次内容根据2017年11月4日 K8S Geek Gathering 沙龙深圳站腾讯云高级工程师王天夫的演讲内容整理而成。

本次分享的主要内容涉及腾讯云容器的顶层整体设计，包括产品功能，及提供的附加能力。同时会介绍我们现在Master集群化部署的整体方案。通过这些内容的提前了解，可以更好理解后面和大家分享的关于容器监控的内容，所有监控的设计都是依赖于Master集群化部署的。最后会和大家分享腾讯云容器服务监控的Future Work。

大家可以看一下这个图，这是腾讯云容器服务PaaS平台顶层的设计，最上面是云Portal，意义是用户在使用我们容器服务的时候能够从这几个维度去掌控他们的集群、创建他们的容器。第一个是MC，可以理解为是控制管理台，大家都知道Kubernetes本身的概念是比较复杂的，对一个刚刚接手Kubernetes的人来说理解成本是特别大的，我们在Kubernetes之上包装了它的概念，对于刚刚接手的人来说是非常好的理解。同时可视化出来提供页面给大家用。第二点是支持原生的K8S API，因为整个容器服务是基于K8S开发的，为了保证用户使用不同的Kubernetes，所以我们在Kubernetes主干上并不会去做很大的改动，因为一开始我们是做过这方面的东西，但是我们发现如果我们在K8S上做了特别大的改动，在第二次提供给用户或者升级的时候，是一个非常困难的事情，因为大家知道K8S的迭代是非常快的，大概是半年到一年时间就会升级一个大版本，所以我们基本上都是原生基于K8S开发。最后我们还把我们自己包装的概念通过一个云API提供给用户使用，因为现在很多的用户都是有自己的运营系统的，他们会使用云API去封装一些自己的运营平台，所以我们这里也支持了一下。

中间这块是整个容器服务三个大部分，第一块是整个CCS，这块提供了如下的功能，像集群管理、模板应用管理，应用管理这里指的是我们会把所有的服务包装成一个大的应用，方便用户去一键部署自己的应用。第三个是服务管理，我们把K8S里面提到的概念，像deployment,service,pod封装成服务的概念提供给用户，后面还有日志、券和配额，这些都是我们这边开发的。最底层，因为我们要支持原生的Kubernetes，所以不可避免的需要有些开发，比如和IaaS层、PaaS层的打通，就需要有日志、网络、券、负载均衡的驱动开发。第二块是CCR，是我刚才提到的镜像服务。镜像服务支持有多个hub源的镜像，还有自建的Cloud的镜像，还有第三方的也支持。同时我们做了一些比较重要的优化，我们在海外搭建了很多节点，帮助用户能够快速的拉取镜像，并且做成mirror，同时我们的镜像仓库是分地域部署。同时我们还会定时拉去Docker Hub上的镜像做缓存，进一步提升效率。最后一块是CI/CD，CI/CD是去定义自动部署、自动构建的策略，例如提交代码时自动触发。

下面是我现在负责的CCS-Monitor Server，包括监控上面整套容器服务的体系。最底下是对我们自己腾讯云的IaaS和PaaS层的集合，譬如说CVM、黑石，大家可以理解为公有云和私有云，同时我们集成块存储、对象存储、CFS，我们还有日志中心，后面我会讲一下。最后还有弹性伸缩和负载均衡，弹性伸缩主要可以理解为HPA和HNA，这是腾讯服务顶层的计。

接下来第二点，给大家讲一下腾讯云Master集群化部署。下图是现在腾讯容器服务Master集群化部署的概览，我给大家说一下大概的背景。当初腾讯云的容器服务刚开始上线的时候，这个地方并不是这样子的。

刚开始我们会为用户的每个集群创建一个Master，这个Master当初是一个虚拟机，为了做高可用，我们会为用户再部署一个stand by的Master，当Master出现故障的时候，我们可以方便的切换。

最后就造成很多多的问题，一是成本的问题，如果每个集群都部署一个Master，部署一台虚拟机，成本很大。二是运维成本，每台Master都是一台虚拟机，每个master的组件，是一个二进制文件部署在Master上面。这种情况下，如果对某个Master进行升级，不可避免的就会出现很多问题。

基于这个考虑，我们重新优化了整个我们的Master部署，我们采用的方案是调研了社区里面一些热门的方案，这个方案就是kubernetes in kubernetes，不知道大家有没有了解过这个东西。我们单独部署一套K8S集群，所有Master的组件，大家知道的三大组件都会以pod的形式运行在K8S集群中。我们为Pod绑定双网卡，一个网卡是弹性网卡，它会单独与用户的VPC做网络通信，另外一个网卡是原生的，这个网卡会是Master集群中使用的网卡。

每个API的组件都是一个Pod，好处是，一是Master集群的部署，主要是以K8S管理，这样HA、SLA都有很大的保证，包括后面运维的提升，可以使用K8S原生的rolling update去操作。其次是成本，有些用户可能Master不需要那么大的CPU Memory，我们可以共同调整CPU Memory的request，同时对于大型的客户，譬如说在集群中运行了上千个Pod情况下，通过动态调整扩展Master的配置，增大更多的Api server做一个负载调优。

这里大概讲了现在集群化部署的方案，后面我监控的方案都会依赖于这个，给大家稍微先讲一下这块。

第三，基础的指标监控。我们的基础指标监控主要还是以IaaS层为主，就是大家所说的Cpu,Memory、DiSK和Network方面。这里一共有四块，Node、Deployment，Deployment，Pod，container，所有IaaS层的监控指标都会依照这四个模块来做聚合。

上面的四块是我讲的IaaS层基础指标，这里我选取了几个重要的指标，如果大家以后有自建容器监控，希望对大家有所帮助。CPU Memory有些指标是非常重要的，例如CPU Usage和Memory Usage，这里的Cpu Usage和Memory Usage是占整个pod request或者 limit的整个比例，如果这两个指标比较高，就必须警觉起来，可能会造成pod不可用的问题发生，另外我提一下，大家知道，在K8S中，有一个request 和limit的概念，如果request limit不配置，在一些测试环境，不知道大家有没有试过，当一个Pod跑到很高的情况下，会出现雪崩的效应，比如跑挂一台机器，这时候挂了之后，节点异常，K8S会自动的把这台机器上所有的Pod踢走，Pod会自动创建到另外的机器上，继续拖垮另外一台机器，这种可以称之为“雪崩效应”。最后造成的结果是K8S集群不可用。其次，CPU node和Memory node。当前你的K8S集群中还有剩余的CPU和Memory可分配的比例，当一个K8S pod配置的request limit不能满足当前集群中所剩余的量，就会造成，新的Pod无法调度。Network比较基本，一个是进出带宽、进出流量，还有进出包量。Disk有几个比较重要的，traffic、iops，这些自己自建的时候也需要关注。

最后单独提一下Inode，有一次用户使用过程发现Pod创建不成功，经过多方面调查，发现Inode满了，为什么出现这种情况？我们看了K8S代码，它对镜像和日志都有回收机制，但是对Inode的回收和清理是没有的，社区也有讨论，但是一直没有解决。所以说Inode这块是必须要监控起来的，它会造成你整个集群中某个节点无法创建服务，所以说我单独把它拎出来和大家提一下，我不知道现在的1.8版本有没有解决这个问题。

最后是LB的监控，大家可以知道，servers有几种提供的访问方式，腾讯云容器服务的servers与腾讯云的LB做了绑定，用户创建servers的时候，如果指定的方式是LB，我们通过插件的方式帮他申请一个LB挂在上面，不管是内网还是外网。用户对自己服务的监控，我们可以通过LB的Httpcode和当前的连接数、回包的时间等指标去做，就能准确的判断出当前业务的健康状态。

这是基础监控指标大概的架构（见下图）。我们主要使用开源的方式，大家在网上关注监控就知道，容器的监控大概有这么几种方案，当时我们做方案评估的时候也考虑过其他几种，最后还是选择了heapster的方式，还是业务驱动，因为调研的时候发现cadvisor对K8S中的聚合没有做得特别好，它的数据都是原始的数据，如果我们在以Kubernetes的方式聚合，这是很复杂的。普罗米修斯，我们考虑它比较重，一个是集收集，告警和存储一体的，我们需要的仅仅是收集这块，所以说普罗米修斯并不适合我们这里的业务，最后我们就选择使用heapster。我们这里的heapster也是以容器的方式部署在Master集群化部署的集群里面，对用户是无感知的，也不消耗用户的资源。其次heapster我们帮它绑定两张网卡，一张是去用户的集群中拉取监控数据，因为大家知道heapster需要与Kubernetes通信，拉取一些监控数据，所以我们这里必须绑定两张网卡。其次我们会构建一个CCS Monitorserver，定时拉取一些集群的监控数据，做一些汇总或计算。最后，我们会把这些收集到的数据Push到Barad server，这可以理解为腾讯云整个监控的组件，这是平台级的组件。Barad server做了几件事，一是聚合，会把我们所有上报的指标聚合成，比如我们加一些时间粒度的汇总，1分钟、5分钟、10分钟这种，包括我们以Node的形式展示出整个Node下所有pod平均的监控指标。做这种聚合。最后我们会提供云API的方式给接入层使用，接入层主要是用户调取需要的监控指标，还有HPA和HNA，就是Pod和Node水平扩展，这个是我们直接拉取Barad API的数据做扩展工作。

第四，事件指标。其实在问题发生的时候，如果仅仅只看基础的监控指标是远远不够的，因为你只能发现你的服务出现了问题，但是你不能很好的去知道到底是哪个服务出现了问题，事件指标主要如下几个问题：1、汇聚当前K8S所有资源事件的汇总，我们会根据这些事件做自己的提炼，同时push到事件中心。2、事件中心指标弥补指标监控信息部直接的短板，我刚才说到过。3、提高问题的定位效率。4、事件指标支持告警。事件指标主要分两大块：1、异常事件；2、状态事件。异常事件大家可以理解为Pod创建失败、重启、节点异常、内存不足、调度失败的事件。状态事件是一些正常事件，比如Pod启动、销毁、更新中、HPA触发、HNA触发。它对对于定位问题也有很大的帮助。

事件指标的整体方案，我们当前是从API server中拉取K8S所有的事件，会存储在ES集群中，我们会有内部的Cluster做数据的查询和展示。ES中汇聚的都是每条基础数据，也就是大家俗称的源数据。其次CCS Monitor会把它合并成用户能够理解的汇总的数据，然后推到腾讯云事件中心去。最后用户可以在控制台上看到这个事件发生的原因、属于哪个资源，最后还会告诉它如何解决这个问题，会有一个帮助文档。

第五，整个监控中对腾讯最重要的是集群稳定性的监控。这里的图会有点问题，集群稳定性的监控分为四大块，Kube-System和ETCD、Master相关组件监控，比如API server等，最重要的是运行时问题监控。

集群稳定性监控采用三个开源的方案，一是Node Detector，主要是做运行时。Fluentd主要是采集每个Master集群上每个容器的node，后面也用了普罗米修斯的方案，没有再使用heapster，因为普罗米修斯，我们需要它做一些存储，不需要做对外展示，这是内部使用，所以我们需要采用普罗米修斯去定制一些东西去采集更多的指标。大家可以看到整个Master集群上，每个Master集群上每个node部署的各个pod，Fluentd会拉取lod。普罗米修斯我们自己定制了一些插件，在每个pod上拉取一些我们基本的指标。同时Node Detector部署在每个用户节点上，这是用户可以自己选择的。它主要采集一些Kernel和runtime的问题。Node Detector是K8S官方的项目，如果大家感兴趣可以了解一下。

第六，最后一个监控组件，业务日志监控。大家知道业务日志对于一个问题定位帮助是非常大的，如果一个监控仅仅只有事件和指标，其实很多问题都无法定位，因为容器在使用的时候，更多的会动态的增加和减少。所以我们这里会采集容器日志，并且保存在日志服务中，供用户在后期能更方便的去追溯到原来的一些业务问题。业务日志分四个板块，容器日志的收集和节点日志的收集，还有日志存储和日志处理，现在容器日志也是前面提到的stdout和stderr日志，并且附加相关的Kubernetes Metadata，主机特定目录的日志并附加指定的label去收集用户容器达到主机上固定的日志。存储方面，我们支持把日志发送到用户自己搭建的Kafka或者ES或者腾讯云的日志服务中存储起来做消费。最后一块是日志处理，日志处理主要是方便用户能够去方便定位问题，同时我们支持能够根据一定关键字配置一些关键字的告警，最后我们后续可能还会支持做一些大数据的处理工作。

整个业务日志的监控整体的方案（见PPT），我们让用户定义一个个不同的规则，不同的规则可以叫collector，所有的collector会并成一个Config Map，在启动Fluentd的时候会收集Cluster指定的收集策略，最后发送到不同的后端源，当时做这套设计的时候我们考虑其他组件的方案，主要采集的agent，我们考虑了filebeat和fluentd,最后我们采用的还是fluentd，一是基于性能的考虑，fluentd是c和ruby写的，消耗只有在40M左右，filebeat会更大一些。最重要的一点是fluentd支持数据源推的路由，也就是说它能够通过不同的规则、不同的lable去推到不同的终端上。例如我有一条规则A和规则B，它分别推到ES或者Ckafka，所以我们最后就选择了fluentd的方案做业务日志的收集。

最后讲一下我们后期调研的工作和待开发的工作：1、自定义监控。自定义希望让用户能够自己去定义一些监控指标，自己Push一些监控指标到我们的监控平台。2、调用链追踪和Real-time Monitor的部署，当一个应用起来之后，会有成千上百的容器在里面传输，调用链就是非常直观的监控方向,同时配合realtimemonitor，能够很好的发现服务的健康状态，其次我们还会提供一个应用市场，因为现在普遍上开源也有很多的监控方案，我们会把它打包成一个个应用提供给用户使用，最后两点就是告警的预测和集群网络的监控，告警预测我们希望通过我们收集的数据去分析可能发生的问题，例如说当一个时间点内某项指标与前段时间周期性比较的指标的发生很大差异的时候，我们需要能够及时的通知用户，这里可能会出现了问题。集群网络的监控方面，我们发现用户在部署的集群的时候，经常有些iptables，ACL，或者timeout等网络的问题，这块的监控后期同样会补上。

最近正在制定将团队生产环境的Kubernetes集群从1.6升级1.7的计划。 Kubernetes 1.8已经发布，所以准备考虑从1.6到1.7的升级。

准备

当前1.7的最新版本是1.7.8。在做准备之前需要仔细读一遍官方的Kubernetes 1.7 (https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.7.md#action-required-before-upgrading)。

使用ansible升级k8s的核心组件

目前我们总共有两个高可用的Kubernetes集群，分别是测试环境和生产环境，版本都是1.6.10。 这两套环境的Kubernetes集群都是基于ansible自动部署，在1.6.x的每个小版本的升级也都是使用ansible完成。

这里准备的升级步骤是本地VM环境 => 测试环境 => 生产环境。 先使用ansible在本地VM中部署k8s 1.6.10的集群，然后再使用ansible将本地1.6升级到1.7并做一些验证，再升级测试环境，测试环境稳定运行一段时间后完成生产环境的升级。

本地VM环境中的ansible play的十分顺利，集群的各个核心组件已经成功的升级到1.7.8。

以容器形式运行组件的升级

接下来要对一些以容器形式运行的组件升级，对应版本如下：

• flannel 0.9.0
• kube-dns 1.14.5
• dashboard 1.7.1

升级kube-dns的注意事项

kube-dns 1.14.5部署文件的地址在gitlab中发生了变化，在内容上使用Deployment替换了Replication Controller。

wget https://raw.githubusercontent.com/kubernetes/kubernetes/e1d6bcc22736a15ce662b3bd1009a16cdde5cd86/cluster/addons/dns/kube-dns.yaml.base
wget https://raw.githubusercontent.com/kubernetes/kubernetes/e1d6bcc22736a15ce662b3bd1009a16cdde5cd86/cluster/addons/dns/transforms2sed.sed

查看transforms2sed.sed：

s/__PILLAR__DNS__SERVER__/$DNS_SERVER_IP/g
s/__PILLAR__DNS__DOMAIN__/$DNS_DOMAIN/g
s/__MACHINE_GENERATED_WARNING__/Warning: This is a file generated from the base underscore template file: __SOURCE_FILENAME__/g

将$DNS_SERVER_IP替换成10.96.0.10，将DNS_DOMAIN替换成cluster.local。 注意$DNS_SERVER_IP要和kubelet设置的–cluster-dns参数一致

执行：

cd ~/k8s/kube-dns
sed -f transforms2sed.sed kube-dns.yaml.base > kube-dns.yaml

• 上面的变量DNS_SERVER要和kubelet设置的–cluster-dns参数一致。

kubectl create -f kube-dns.yaml

查看kube-dns的Pod，确认所有Pod都处于Running状态：

kubectl get pods --all-namespaces
NAMESPACE     NAME                                    READY     STATUS    RESTARTS   AGE
kube-system   kube-dns-3468831164-chjw5               3/3       Running   0          3m

测试一下DNS功能是否好用：

kubectl run curl --image=radial/busyboxplus:curl -i --tty

nslookup kubernetes.default
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local

kube-dns是Kubernetes实现服务发现的重要组件之一，默认情况下只会创建一个DNS Pod，在生产环境中我们可能需要对kube-dns进行扩容。 有两种方式：

• 手动扩容 kubectl –namespace=kube-system scale deployment kube-dns –replicas=

• 使用DNS Horizontal Autoscaler

升级dashboard的注意事项

因为之前部署Dashboard 1.6时创建了ServiceAccount kubernetes-dashboard，并分配了cluster-admin的权限。 所以在升级前应该先删除掉这个ServiceAccount：

kubectl delete  serviceaccount kubernetes-dashboard -n kube-system
kubectl delete  clusterrolebinding kubernetes-dashboard

1.7.x版本的dashboard对安全做了增强，默认需要以https的方式访问，增加了登录的页面，同时增加了一个gcr.io/google_containers/kubernetes-dashboard-init-amd64的init容器。

另外需要注意dashboard调整了部署文件的源码目录结构：

mkdir -p ~/k8s/
wget https://raw.githubusercontent.com/kubernetes/dashboard/b44f7cc5fde4dbe2a884b1e32a2b363d8031e4ca/src/deploy/recommended/kubernetes-dashboard.yaml
kubectl create -f kubernetes-dashboard.yaml

kubernetes-dashboard.yaml文件中的ServiceAccount kubernetes-dashboard只有相对较小的权限，因此我们创建一个kubernetes-dashboard-admin的ServiceAccount并授予集群admin的权限，创建kubernetes-dashboard-admin.rbac.yaml：

---
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard-admin
  namespace: kube-system

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: kubernetes-dashboard-admin
  labels:
    k8s-app: kubernetes-dashboard
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard-admin
  namespace: kube-system

kubectl create -f kubernetes-dashboard-admin.rbac.yaml
serviceaccount "kubernetes-dashboard-admin" created
clusterrolebinding "kubernetes-dashboard-admin" created

查看kubernete-dashboard-admin的token:

kubectl -n kube-system get secret | grep kubernetes-dashboard-admin
kubernetes-dashboard-admin-token-mrngz   kubernetes.io/service-account-token   3         18m

kubectl describe -n kube-system secret kubernetes-dashboard-admin-token-mrngz
Name:           kubernetes-dashboard-admin-token-mrngz
Namespace:      kube-system
Labels:         <none>
Annotations:    kubernetes.io/service-account.name=kubernetes-dashboard-admin
                kubernetes.io/service-account.uid=906d3aa6-b06d-11e7-afdd-080027d9d784

Type:   kubernetes.io/service-account-token

Data
====
ca.crt:         1302 bytes
namespace:      11 bytes
token:          ......

在dashboard的登录窗口使用上面的token登录。

【编者的话】希望这篇文章可以帮助大家更好的了解Kubernetes的相关核心内容。

当检查你的Kubernetes集群的节点时，在节点上执行命令docker ps，你可能会注意到一些被称为“暂停（/pause）”的容器。

$ docker ps
CONTAINER ID IMAGE COMMAND ...
...
3b45e983c859 gcr.io/google_containers/pause-amd64:3.0  “/pause” ...
...
dbfc35b00062 gcr.io/google_containers/pause-amd64:3.0  “/pause” ...
...
c4e998ec4d5d gcr.io/google_containers/pause-amd64:3.0  “/pause” ...
...
508102acf1e7 gcr.io/google_containers/pause-amd64:3.0  “/pause” ...

这些“暂停”容器是啥，而且还这么多暂停的？这到底是什么情况？

为了回答这些问题，我们需要退一步看看Kubernetes中的pods如何实现，特别是在Docker/containerd运行时。如果你还不知道怎么做，可以先阅读我以前发表的关于Kubernetes pods 的文章(http://dockone.io/article/2682)。

Docker支持容器，这非常适合部署单个软件单元。但是，当你想要一起运行多个软件时，这种模式会变得有点麻烦。当开发人员创建使用supervisord作为入口点的Docker镜像来启动和管理多个进程时，你经常会看到这一点。对于生产系统，许多人发现，将这些应用程序部署在部分隔离并部分共享环境的容器组中更为有用。

Kubernetes为这种使用场景提供了一个称为Pod的干净的抽象。它在隐藏Docker标志的复杂性的同时会保留容器，共享卷等。它也隐藏了容器运行时的差异。例如，rkt原生支持Pod，所以Kubernetes的工作要少一些，但是不管怎样，作为Kubernetes用户的你都不用担心（Pod会帮你搞定这些）。

原则上，任何人都可以配置Docker来控制容器组之间的共享级别——你只需创建一个父容器，在知道正确的标志配置的情况下来设置并创建共享相同环境的新容器，然后管理这些容器的生命周期。而管理所有这些片段的生命周期可能会变得相当复杂。

在Kubernetes中，“暂停”容器用作你的Pod中所有容器的“父容器”。“暂停”容器有两个核心职责。首先，在Pod中它作为Linux命名空间共享的基础。其次，启用PID（进程ID）命名空间共享，它为每个Pod提供PID 1，并收集僵尸进程。

共享命名空间

在Linux中，当你运行新进程时，该进程从父进程继承其命名空间。在新命名空间中运行进程的方法是通过“取消共享”命名空间（与父进程），从而创建一个新的命名空间。以下是使用该unshare工具在新的PID，UTS，IPC和装载命名空间中运行shell的示例。

sudo unshare --pid --uts --ipc --mount -f chroot rootfs / bin / sh

一旦进程运行，你可以将其他进程添加到进程的命名空间中以形成一个Pod。可以使用setns系统调用将新进程添加到现有命名空间。

Pod中的容器在其中共享命名空间。Docker可让你自动执行此过程，因此，让我们来看一下如何使用“暂停”容器和共享命名空间从头开始创建Pod的示例。首先，我们将需要使用Docker启动“暂停”容器，以便我们可以将容器添加到Pod中。

docker run -d --name pause gcr.io/google_containers/pause-amd64:3.0

然后我们可以运行我们的Pod的容器。首先我们将运行Nginx。这将在端口2368上设置Nginx到其localhost的代理请求。

$ cat <<EOF >> nginx.conf
> error_log stderr;
> events { worker_connections  1024; }
> http {
>     access_log /dev/stdout combined;
>     server {
>         listen 80 default_server;
>         server_name example.com www.example.com;
>         location / {
>             proxy_pass http://127.0.0.1:2368;
>         }
>     }
> }
> EOF
$ docker run -d --name nginx -v `pwd`/nginx.conf:/etc/nginx/nginx.conf -p 8080:80 --net=container:pause --ipc=container:pause --pid=container:pause nginx 

然后，我们将为作为我们的应用服务器的ghost博客应用程序创建另一个容器。

$ docker run -d --name ghost --net = container：pause --ipc = container：pause --pid = container：pause ghost

在这两种情况下，我们将“暂停”容器指定为我们要加入其命名空间的容器。这将有效地创建我们的Pod。如果你访问 http://localhost:8080/ 你应该能够看到ghost通过Nginx代理运行，因为网络命名空间在pause，nginx和ghost容器之间共享。

如果你觉得这一切好复杂，恭喜你，大家都这么就觉得；它确实很复杂（感觉像句废话）。而且我们甚至还没有了解如何监控和管理这些容器的生命周期。不过，值得庆幸的事，通过Pod，Kubernetes会为你很好地管理所有这些。

收割僵尸

在Linux中，PID命名空间中的所有进程会形成一个树结构，每个进程都会有一个父进程。只有在树的根部的进程没有父进程。这个进程就是“init”进程，即PID 1。

进程可以使用fork和exec syscalls启动其他进程。当启动了其他进程，新进程的父进程就是调用fork syscall的进程。fork用于启动正在运行的进程的另一个副本，而exec则用于启动不同的进程。每个进程在OS进程表中都有一个条目。这将记录有关进程的状态和退出代码。当子进程运行完成，它的进程表条目仍然将保留直到父进程使用wait syscall检索其退出代码将其退出。这被称为“收割”僵尸进程。

僵尸进程是已停止运行但进程表条目仍然存在的进程，因为父进程尚未通过wait syscall进行检索。从技术层面来说，终止的每个进程都算是一个僵尸进程，尽管只是在很短的时间内发生的，但只要不终止他们就可以存活更久。

当父进程wait在子进程完成后不调用syscall时，会发生较长的生存僵尸进程。这样的情况有很多，比如：当父进程写得不好并且简单地省略wait call时，或者当父进程在子进程之前死机，并且新的父进程没有调用wait去检索子进程时。当进程的父进程在子进程之前死机时，OS将子进程分配给“init”进程即PID 1。init进程“收养”子进程并成为其父进程。这意味着现在当子进程退出新的父进程（init）时，必须调用wait 来获取其退出代码否则其进程表项将保持永远，并且它也将成为一个僵尸进程。

在容器中，一个进程必须是每个PID命名空间的init进程。使用Docker，每个容器通常都有自己的PID命名空间，ENTRYPOINT进程是init进程。然而，正如我在上一篇关于Kubernetes Pods的文章 (http://dockone.io/article/2682) 中所指出的，某个容器可以在另一个容器的命名空间中运行。在这种情况下，这个容器必须承担init进程的角色，而其他容器则作为init进程的子进程添加到命名空间中。

在Kubernetes Pods的文章中，我在一个容器中运行Nginx，并将ghost添加到了Nginx容器的PID命名空间。

$ docker run -d --name nginx -v `pwd`/nginx.conf:/etc/nginx/nginx.conf -p 8080:80 nginx
$ docker run -d --name ghost --net=container:nginx --ipc=container:nginx --pid=container:nginx ghost

在这种情况下，Nginx将承担PID 1的作用，并将ghost添加为Nginx的子进程。虽然这样貌似不错，但从技术上来看，Nginx现在需要负责任何ghost进程的子进程。例如，如果ghost分身或者使用子进程运行exec，并在子进程完成之前崩溃，那么这些子进程将被Nginx收养。但是，Nginx并不是设计用来作为一个init进程运行并收割僵尸进程的。这意味着将会有很多的这种僵尸进程，并且在整个容器的生命周期，他们都将持续存活。

在Kubernetes Pods中，容器的运行方式与上述方式大致相同，但是每个Pod都有一个特殊的“暂停”容器。这个“暂停”容器运行一个非常简单的进程，它不执行任何功能，基本上是永远睡觉的（见pause()下面的调用）。因为它比较简单，在这里写下完整的源代码，如下：

/*
Copyright 2016 The Kubernetes Authors.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/
include <signal.h>

include <stdio.h>

include <stdlib.h>

include <sys/types.h>

include <sys/wait.h>

include <unistd.h>

static void sigdown(int signo) {
psignal(signo, "Shutting down, got signal");
exit(0);
}

static void sigreap(int signo) {
while (waitpid(-1, NULL, WNOHANG) > 0);
}

int main() {
if (getpid() != 1)
/* Not an error because pause sees use outside of infra containers. */
fprintf(stderr, "Warning: pause should be the first processn");

if (sigaction(SIGINT, &(struct sigaction){.sa_handler = sigdown}, NULL) < 0)
return 1;
if (sigaction(SIGTERM, &(struct sigaction){.sa_handler = sigdown}, NULL) < 0)
return 2;
if (sigaction(SIGCHLD, &(struct sigaction){.sa_handler = sigreap,
                                         .sa_flags = SA_NOCLDSTOP},
            NULL) < 0)
return 3;

for (;;)
pause();
fprintf(stderr, "Error: infinite loop terminatedn");
return 42;
} 

正如你所看到的，它当然不会只知道睡觉。它执行另一个重要的功能——即它扮演PID 1的角色，并在子进程被父进程孤立的时候通过调用wait 来收割这些僵尸子进程（参见sigreap）。这样我们就不用担心我们的Kubernetes Pods的PID命名空间里会堆满僵尸了。

PID命名空间共享的一些上下文

值得注意的是，PID命名空间共享已经有了很多的前后关系。如果你启用了PID命名空间共享，那么只能通过暂停容器来收割僵尸，并且目前这一功能仅在Kubernetes 1.7+以上的版本中可用。如果使用Docker 1.13.1+运行Kubernetes 1.7，这一功能默认是开启的，除非使用kubelet标志（–docker-disable-shared-pid=true）禁用。这在Kubernetes 1.8 中正好相反的，现在默认情况下是禁用的，除非由kubelet标志（–docker-disable-shared-pid=false）启用。感兴趣的话，可以看看在GitHub issue中对增加支持PID命名空间共享的有关讨论。

如果没有启用PID命名空间共享，则Kubernetes Pod中的每个容器都将具有自己的PID 1，并且每个容器将需要收集僵尸进程本身。很多时候，这不是一个问题，因为应用程序不会产生其他进程，但僵尸进程使用内存是一个经常被忽视的问题。因此，由于PID命名空间共享使你能够在同一个Pod中的容器之间发送信号，我衷心的希望PID命名空间共享可以成为Kubernetes中的默认选项。

Kubernetes架构下比较核心的问题是数据如何persistance,虽然提供了Persistent volumn的方式，但是对于像数据库之类的产品在kubernetes集群环境中运行和管理还是很有难度的，Kubernetes提供了endpoints这种模式让外部的服务映射成内部的服务，这样比较好的解决了集群对外的连接问题，

如果我们去连接外部的一个oracle数据库，具体的步骤如下:

• 建立endpoints和service.

[root@k8s-master jdbcservice]# cat jdbc-endpoint.yaml 
apiVersion: v1
kind: Endpoints
metadata:
  name: jdbc
subsets:
  - addresses:
    - ip: 10.182.168.244
    ports:
    - port: 1521
      protocol: TCP

为了方便，我们固定了service的集群地址

[root@k8s-master jdbcservice]# cat jdbcservice.yaml 
apiVersion: v1
kind: Service
metadata:
  name: jdbc
spec:
  clusterIP: 10.254.150.201
  ports:
  - port: 1521
    targetPort: 1521
    protocol: TCP

需要注意的是，service和endpoints的名字要相同，另外如果delete了service.再重新建立的时候要再把endpoints建立一遍。

在这个service的表里，我们看到jdbc服务绑在了201这个地址上。

[root@k8s-master jdbcservice]# kubectl get services
NAME            CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
helloworldsvc   10.254.43.122    <nodes>       7001:30001/TCP   12m
jdbc            10.254.150.201   <none>        1521/TCP         30m
kubernetes      10.254.0.1       <none>        443/TCP          121d
registry        10.254.174.54    <nodes>       5000:30002/TCP   20h

• images的配置

然后对我们的weblogic images进行jdbc的配置。

点击Test Configuration,如果测试不过，weblogic不允许建立连接池成功.

在运行pod的节点上运行docker ps找到启动image的容器id.

[root@k8s-node-1 ~]# docker ps
CONTAINER ID        IMAGE                                                        COMMAND                  CREATED             STATUS              PORTS               NAMES
d2c1dc2a2cef        1213-helloworld:v1                                           "startWebLogic.sh"       7 minutes ago       Up 7 minutes                            k8s_weblogichelloworld.9efb3a79_helloworld-service-vfd10_default_6162d68a-9da9-11e7-b746-08002797edef_026d2cc4
85e04042041a        registry.access.redhat.com/rhel7/pod-infrastructure:latest   "/pod"                   7 minutes ago       Up 7 minutes                            k8s_POD.15c40ba1_helloworld-service-vfd10_default_6162d68a-9da9-11e7-b746-08002797edef_b59984a7
96acfd65eb3a        registry                                                     "/entrypoint.sh /etc/"   23 minutes ago      Up 23 minutes                           k8s_registry.71ab5625_registry-7nj8q_default_19ab0b7f-9cff-11e7-bf9d-08002797edef_fb5ae620
63652932256c        registry.access.redhat.com/rhel7/pod-infrastructure:latest   "/pod"                   23 minutes ago      Up 23 minutes                           k8s_POD.100f0b9e_registry-7nj8q_default_19ab0b7f-9cff-11e7-bf9d-08002797edef_98dd7f3f
1ed61c53625f        gcr.io/google_containers/etcd-amd64:2.2.1                    "/usr/local/bin/etcd "   47 minutes ago      Up 47 minutes                           k8s_etcd.bb974d90_kube-dns-v11-x0vr3_kube-system_5dd26461-3ef1-11e7-acf2-08002797edef_7316989c
fb8545a4aba4        gcr.io/google_containers/exechealthz:1.0                     "/exechealthz '-cmd=n"   47 minutes ago      Up 47 minutes                           k8s_healthz.525e4aad_kube-dns-v11-x0vr3_kube-system_5dd26461-3ef1-11e7-acf2-08002797edef_cec4d740
aa6c4caf3fa7        gcr.io/google_containers/skydns:2015-10-13-8c72f8c           "/skydns -machines=ht"   47 minutes ago      Up 47 minutes                           k8s_skydns.96837166_kube-dns-v11-x0vr3_kube-system_5dd26461-3ef1-11e7-acf2-08002797edef_5da89b81
5930dae5b843        registry.access.redhat.com/rhel7/pod-infrastructure:latest   "/pod"                   47 minutes ago      Up 47 minutes                           k8s_POD.4efc54ff_kube-dns-v11-x0vr3_kube-system_5dd26461-3ef1-11e7-acf2-08002797edef_3e3af088

生成新的images

[root@k8s-node-1 ~]# docker commit -m "jdbc" -a "ericnie" d2c1dc2a2cef 1213-helloworld-jdbc:v1
sha256:953e124483d2bcc03b3f46c8e6d935e3746634d78942cc477e31888c8d569171

• 验证

修改weblogic replication control指向1213-helloworld-jdbc:v1 images,启动后看到连接建立.

weblogic端

数据库端

数据库端原来的jdbc链接

Pod完全启动后的连接