本文转自：http://blog.csdn.net/xingwangc2014/article/details/
kubernetes通过kube-apiserver作为整个集群管理的入口。Apiserver是整个集群的主管理节点，用户通过Apiserver配置和组织集群，同时集群中各个节点同etcd存储的交互也是通过Apiserver进行交互。Apiserver实现了一套RESTfull的接口，用户可以直接使用API同Apiserver交互。另外官方还提供了一个客户端kubectl随工具集打包，用于可直接通过kubectl以命令行的方式同集群交互。
由于博主水平有限，本文主要介绍一些博主在日常中经常使用到的命令，另外最近正式release的kubernetes 1.2中新加入的的一些feature，由于博主也还没有深入研究，所以不会太多涉及。
类似于所有的命令行工具工具，kubectl也可以直接执行&kubectl&或&kubectl help& | &kubectl --help&可获得命令的帮助信息。如下图所示，kubectl使用方式为：
kubectl [flags]
kubectl [commond]
另外所有的命令选项都可以通过执行 --help获得特定命令的帮助信息。
get命令用于获取集群的一个或一些resource信息。使用--help查看详细信息。kubectl的帮助信息、示例相当详细，而且简单易懂。建议大家习惯使用帮助信息。kubectl可以列出集群所有resource的详细。resource包括集群节点、运行的pod，ReplicationController，service等。
kubectl get [(-o|--output=)json|yaml|wide|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...] (TYPE [NAME | -l label] | TYPE/NAME ...) [flags] [flags]
1）例如获取pod信息，可以直接使用"kubectl get po&获取当前运行的所有pods的信息，或使用&kubectl get po -o wide&获取pod运行在哪个节点上的信息。注:集群中可以创建多个namespace，未显示的指定namespace的情况下，所有操作都是针对default namespace。如下图所示列出了default 和kube-system的pods：
2）获取namespace信息
# kubectl get namespace
3）类似可以使用"kubectl get rc&, &kubectl get svc&, &kubectl get nodes&等获取其他resource信息。
4）获取一些更具体的信息，可以通过使用选项&-o&。如：
（1）kubectl get po &podname& -o yaml 以yawl格式输出pod的详细信息。
（2）kubectl get po &podname& -o json 以jison格式输出pod的详细信息。
（3）另外还可以使用&-o=custom-columns=&定义直接获取指定内容的值。如前面使用json和ymal格式的输出中，metadata.labels.app的值可以使用如下命令获取。&
kubectl get po rc-nginx-2-btv4j -o=custom-columns=LABELS:.metadata.labels.app
其中LABELS为显示的列标题，&.metadata.labels.app&为查询的域名
（4）其他资源也可以使用类似的方式。
3. describe
describe类似于get，同样用于获取resource的相关信息。不同的是，get获得的是更详细的resource个性的详细信息，describe获得的是resource集群相关的信息。describe命令同get类似，但是describe不支持-o选项，对于同一类型resource，describe输出的信息格式，内容域相同。&& & &注：如果发现是查询某个resource的信息，使用get命令能够获取更加详尽的信息。但是如果想要查询某个resource的状态，如某个pod并不是在running状态，这时需要获取更详尽的状态信息时，就应该使用describe命令。&
kubectl describe po rc-nginx-2-btv4j
&kubectl命令用于根据文件或输入创建集群resource。如果已经定义了相应resource的yaml或json文件，直接kubectl create -f filename即可创建文件内定义的resource。也可以直接只用子命令[namespace/secret/configmap/serviceaccount]等直接创建相应的resource。从追踪和维护的角度出发，建议使用json或yaml的方式定义资源。&& & &如，前面get中获取的两个nginx pod的replication controller文件内容如下。文件名为：rc-nginx.yaml&
apiVersion: v1
kind: ReplicationController
name: rc-nginx-2
replicas: 2
app: nginx-2
containers:
- name: nginx-2
image: xingwangc.docker.rg/nginx
- containerPort: 80
直接使用create则可以基于rc-nginx.yaml文件创建出ReplicationController（rc），rc会创建两个副本：
kubectl create -f rc-nginx.yaml
创建后，使用&kubectl get rc&可以看到一个名为rc-nginx-2的ReplicationController将被创建，同时&kubectl get po&的结果中会多出两个前缀为&rc-nginx-2-&的pod。关于kubernetes集群中resource，pod， ReplicationController&等后续会新开博文详细介绍。
5. replace
replace命令用于对已有资源进行更新、替换。如前面create中创建的nginx，当我们需要更新resource的一些属性的时候，如果修改副本数量，增加、修改label，更改image版本，修改端口等。都可以直接修改原yaml文件，然后执行replace命令。&& & &注：名字不能被更新。另外，如果是更新label，原有标签的pod将会与更新label后的rc断开联系，有新label的rc将会创建指定副本数的新的pod，但是默认并不会删除原来的pod。所以此时如果使用get po将会发现pod数翻倍，进一步check会发现原来的pod已经不会被新rc控制，此处只介绍命令不详谈此问题，好奇者可自行实验。
kubectl replace -f rc-nginx.yaml
如果一个容器已经在运行，这时需要对一些容器属性进行修改，又不想删除容器，或不方便通过replace的方式进行更新。kubernetes还提供了一种在容器运行时，直接对容器进行修改的方式，就是patch命令。&& & &如前面创建pod的label是app=nginx-2，如果在运行过程中，需要把其label改为app=nginx-3，这patch命令如下：&
kubectl patch pod rc-nginx-2-kpiqt -p '{"metadata":{"labels":{"app":"nginx-3"}}}'
& & &edit提供了另一种更新resource源的操作，通过edit能够灵活的在一个common的resource基础上，发展出更过的significant resource。例如，使用edit直接更新前面创建的pod的命令为：&
kubectl edit po rc-nginx-btv4j
上面命令的效果等效于：&
kubectl get po rc-nginx-btv4j -o yaml && /tmp/nginx-tmp.yaml
vim /tmp/nginx-tmp.yaml
/*do some changes here */
kubectl replace -f /tmp/nginx-tmp.yaml
& & &根据resource名或label删除resource。&
kubectl delete -f rc-nginx.yaml
kubectl delete po rc-nginx-btv4j
kubectl delete po -lapp=nginx-2
& & &apply命令提供了比patch，edit等更严格的更新resource的方式。通过apply，用户可以将resource的configuration使用source control的方式维护在版本库中。每次有更新时，将配置文件push到server，然后使用kubectl apply将更新应用到resource。kubernetes会在引用更新前将当前配置文件中的配置同已经应用的配置做比较，并只更新更改的部分，而不会主动更改任何用户未指定的部分。&& & &apply命令的使用方式同replace相同，不同的是，apply不会删除原有resource，然后创建新的。apply直接在原有resource的基础上进行更新。同时kubectl apply还会resource中添加一条注释，标记当前的apply。类似于git操作。&& & &&
& & &logs命令用于显示pod运行中，容器内程序输出到标准输出的内容。跟docker的logs命令类似。如果要获得tail -f 的方式，也可以使用-f选项。&
kubectl logs rc-nginx-2-kpiqt
11. rolling-update
& & &rolling-update是一个非常重要的命令，对于已经部署并且正在运行的业务，rolling-update提供了不中断业务的更新方式。rolling-update每次起一个新的pod，等新pod完全起来后删除一个旧的pod，然后再起一个新的pod替换旧的pod，直到替换掉所有的pod。&& & &rolling-update需要确保新的版本有不同的name，Version和label，否则会报错 。
kubectl rolling-update rc-nginx-2 -f rc-nginx.yaml
& &如果在升级过程中，发现有问题还可以中途停止update，并回滚到前面版本&
kubectl rolling-update rc-nginx-2 &rollback
&rolling-update还有很多其他选项提供丰富的功能，如&update-period指定间隔周期，使用时可以使用-h查看help信息&
12. scale&
& & &scale用于程序在负载加重或缩小时副本进行扩容或缩小，如前面创建的nginx有两个副本，可以轻松的使用scale命令对副本数进行扩展或缩小。&扩展副本数到4：
kubectl scale rc rc-nginx-3 &replicas=4
重新缩减副本数到2：
kubectl scale rc rc-nginx-3 &replicas=2
& & &scale虽然能够很方便的对副本数进行扩展或缩小，但是仍然需要人工介入，不能实时自动的根据系统负载对副本数进行扩、缩。autoscale命令提供了自动根据pod负载对其副本进行扩缩的功能。&& & &autoscale命令会给一个rc指定一个副本数的范围，在实际运行中根据pod中运行的程序的负载自动在指定的范围内对pod进行扩容或缩容。如前面创建的nginx，可以用如下命令指定副本范围在1~4&
kubectl autoscale rc rc-nginx-3 &min=1 &max=4
14. cordon, drain, uncordon
& & &这三个命令是正式release的1.2新加入的命令，三个命令一起介绍，是因为三个命令配合使用可以实现节点的维护。在1.2之前，因为没有相应的命令支持，如果要维护一个节点，只能stop该节点上的kubelet将该节点退出集群，是集群不在将新的pod调度到该节点上。如果该节点上本生就没有pod在运行，则不会对业务有任何影响。如果该节点上有pod正在运行，kubelet停止后，master会发现该节点不可达，而将该节点标记为notReady状态，不会将新的节点调度到该节点上。同时，会在其他节点上创建新的pod替换该节点上的pod。这种方式虽然能够保证集群的健壮性，但是任然有些暴力，如果业务只有一个副本，而且该副本正好运行在被维护节点上的话，可能仍然会造成业务的短暂中断。&& & &1.2中新加入的这3个命令可以保证维护节点时，平滑的将被维护节点上的业务迁移到其他节点上，保证业务不受影响。如下图所示是一个整个的节点维护的流程（为了方便demo增加了一些查看节点信息的操作）：1）首先查看当前集群所有节点状态，可以看到共四个节点都处于ready状态；2）查看当前nginx两个副本分别运行在d-node1和k-node2两个节点上；3）使用cordon命令将d-node1标记为不可调度；4）再使用kubectl get nodes查看节点状态，发现d-node1虽然还处于Ready状态，但是同时还被禁能了调度，这意味着新的pod将不会被调度到d-node1上。4）再查看nginx状态，没有任何变化，两个副本仍运行在d-node1和k-node2上；5）执行drain命令，将运行在d-node1上运行的pod平滑的赶到其他节点上；6）再查看nginx的状态发现，d-node1上的副本已经被迁移到k-node1上；这时候就可以对d-node1进行一些节点维护的操作，如升级内核，升级Docker等；7）节点维护完后，使用uncordon命令解锁d-node1，使其重新变得可调度；8）检查节点状态，发现d-node1重新变回Ready状态。&
15. attach
& & &attach命令类似于docker的attach命令，可以直接查看容器中以daemon形式运行的进程的输出，效果类似于logs -f，退出查看使用ctrl-c。如果一个pod中有多个容器，要查看具体的某个容器的的输出，需要在pod名后使用-c containers name指定运行的容器。如下示例的命令为查看kube-system namespace中的kube-dns-v9-rcfuk pod中的skydns容器的输出。&
kubectl attach kube-dns-v9-rcfuk -c skydns &namespace=kube-system
& & &exec命令同样类似于docker的exec命令，为在一个已经运行的容器中执行一条shell命令，如果一个pod容器中，有多个容器，需要使用-c选项指定容器。&
17. port-forward
& & &转发一个本地端口到容器端口，博主一般都是使用yaml的方式编排容器，所以基本不使用此命令。&
& & &博主只尝试过使用nginx作为kubernetes多master HA方式的代理，没有使用过此命令为kubernetes api server运行过proxy&
& & &类似于docker的run命令，直接运行一个image。&
& & &为kubernetes集群的resource打标签，如前面实例中提到的为rc打标签对rc分组。还可以对nodes打标签，这样在编排容器时，可以为容器指定nodeSelector将容器调度到指定lable的机器上，如如果集群中有IO密集型，计算密集型的机器分组，可以将不同的机器打上不同标签，然后将不同特征的容器调度到不同分组上。&& & &在1.2之前的版本中，使用kubectl get nodes则可以列出所有节点的信息，包括节点标签，1.2版本中不再列出节点的标签信息，如果需要查看节点被打了哪些标签，需要使用describe查看节点的信息。&
其他还有如cluster-info信息可以查看当前集群的一些信息，Version查看集群版本信息等，还有一些集群配置相关的命令等。
阅读(...) 评论()20572人阅读
Cloud Computing（6）
Kubernetes是Google开源的容器集群管理系统。它构建于docker技术之上，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能，本质上可看作是基于容器技术的mini-PaaS平台。本文旨在梳理Kubernetes的架构、概念及基本工作流，并且通过运行一个简单的示例应用来介绍如何使用Kubernetes。
如下图所示是我初步阅读文档和源代码之后整理的总体概览，基本上可以从如下三个维度来认识Kubernetes。
Kubernetes以RESTFul形式开放接口，用户可操作的REST对象有三个：
pod：是Kubernetes最基本的部署调度单元，可以包含container，逻辑上表示某种应用的一个实例。比如一个web站点应用由前端、后端及数据库构建而成，这三个组件将运行在各自的容器中，那么我们可以创建包含三个container的pod。
service：是pod的路由代理抽象，用于解决pod之间的服务发现问题。因为pod的运行状态可动态变化(比如切换机器了、缩容过程中被终止了等)，所以访问端不能以写死IP的方式去访问该pod提供的服务。service的引入旨在保证pod的动态变化对访问端透明，访问端只需要知道service的地址，由service来提供代理。
replicationController：是pod的复制抽象，用于解决pod的扩容缩容问题。通常，分布式应用为了性能或高可用性的考虑，需要复制多份资源，并且根据负载情况动态伸缩。通过replicationController，我们可以指定一个应用需要几份复制，Kubernetes将为每份复制创建一个pod，并且保证实际运行pod数量总是与该复制数量相等(例如，当前某个pod宕机时，自动创建新的pod来替换)。
可以看到，service和replicationController只是建立在pod之上的抽象，最终是要作用于pod的，那么它们如何跟pod联系起来呢？这就要引入label的概念：label其实很好理解，就是为pod加上可用于搜索或关联的一组key/value标签，而service和replicationController正是通过label来与pod关联的。如下图所示，有三个pod都有label为&app=backend&，创建service和replicationController时可以指定同样的label:&app=backend&，再通过label
selector机制，就将它们与这三个pod关联起来了。例如，当有其他frontend pod访问该service时，自动会转发到其中的一个backend pod。
如下图所示是官方文档里的集群架构图，一个典型的master/slave模型。
master运行三个组件：
apiserver：作为kubernetes系统的入口，封装了核心对象的增删改查操作，以RESTFul接口方式提供给外部客户和内部组件调用。它维护的REST对象将持久化到etcd（一个分布式强一致性的key/value存储）。
scheduler：负责集群的资源调度，为新建的pod分配机器。这部分工作分出来变成一个组件，意味着可以很方便地替换成其他的调度器。
controller-manager：负责执行各种控制器，目前有两类：
endpoint-controller：定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的。replication-controller：定期关联replicationController和pod，保证replicationController定义的复制数量与实际运行pod的数量总是一致的。
slave(称作minion)运行两个组件：
kubelet：负责管控docker容器，如启动/停止、监控运行状态等。它会定期从etcd获取分配到本机的pod，并根据pod信息启动或停止相应的容器。同时，它也会接收apiserver的HTTP请求，汇报pod的运行状态。
proxy：负责为pod提供代理。它会定期从etcd获取所有的service，并根据service信息创建代理。当某个客户pod要访问其他pod时，访问请求会经过本机proxy做转发。
上文已经提到了Kubernetes中最基本的三个操作对象：pod, replicationController及service。下面分别从它们的对象创建出发，通过时序图来描述Kubernetes各个组件之间的交互及其工作流。
最后，让我们进入实战模式，这里跑一个最简单的单机示例(所有组件运行在一台机器上)，旨在打通基本流程。
第一步，我们需要Kuberntes各组件的二进制可执行文件。有以下两种方式获取：
下载源代码自己编译：
git clone /GoogleCloudPlatform/kubernetes.git
cd kubernetes/build
./release.sh
直接下载人家已经编译打包好的tar文件：
wget /kubernetes/binaries.tar.gz
自己编译源码需要先安装好golang，编译完之后在kubernetes/_output/release-tars文件夹下可以得到打包文件。直接下载的方式不需要安装其他软件，但可能得不到最新的版本。
第二步，我们还需要etcd的二进制可执行文件，通过如下方式获取：
wget /coreos/etcd/releases/download/v0.4.6/etcd-v0.4.6-linux-amd64.tar.gz
tar xvf etcd-v0.4.6-linux-amd64.tar.gz
第三步，就可以启动各个组件了：
cd etcd-v0.4.6-linux-amd64
./apiserver \
-address=127.0.0.1 \
-port=8080 \
-portal_net=&172.0.0.0/16& \
-etcd_servers=http://127.0.0.1:4001 \
-machines=127.0.0.1 \
-logtostderr=false \
-log_dir=./logscheduler
./scheduler -master 127.0.0.1:8080 \
-logtostderr=false \
-log_dir=./log
controller-manager
./controller-manager -master 127.0.0.1:8080 \
-logtostderr=false \
-log_dir=./logkubelet
./kubelet \
-address=127.0.0.1 \
-port=10250 \
-hostname_override=127.0.0.1 \
-etcd_servers=http://127.0.0.1:4001 \
-logtostderr=false \
-log_dir=./log
搭好了运行环境后，就可以提交pod了。首先编写pod描述文件，保存为redis.json：
&id&: &redis&,
&desiredState&: {
&manifest&: {
&version&: &v1beta1&,
&id&: &redis&,
&containers&: [{
&name&: &redis&,
&image&: &dockerfile/redis&,
&imagePullPolicy&: &PullIfNotPresent&,
&ports&: [{
&containerPort&: 6379,
&hostPort&: 6379
&labels&: {
&name&: &redis&
}然后，通过命令行工具kubecfg提交：
./kubecfg -c redis.json create /pods提交完后，通过kubecfg查看pod状态：
# ./kubecfg list /pods
----------
----------
----------
----------
----------
dockerfile/redis
127.0.0.1/
name=redis
Status是Running表示pod已经在容器里运行起来了，可以用&docker ps&命令来查看容器信息:
# docker ps
CONTAINER ID
ae83d1e4b1ec
dockerfile/redis:latest
&redis-server /etc/r
19 seconds ago
Up 19 seconds
k8s_redis.caa18858_redis.default.etcd__1b43fe35
创建replicationController
&id&: &redisController&,
&apiVersion&: &v1beta1&,
&kind&: &ReplicationController&,
&desiredState&: {
&replicas&: 1,
&replicaSelector&: {&name&: &redis&},
&podTemplate&: {
&desiredState&: {
&manifest&: {
&version&: &v1beta1&,
&id&: &redisController&,
&containers&: [{
&name&: &redis&,
&image&: &dockerfile/redis&,
&imagePullPolicy&: &PullIfNotPresent&,
&ports&: [{
&containerPort&: 6379,
&hostPort&: 6379
&labels&: {&name&: &redis&}
&labels&: {&name&: &redis&}
然后，通过命令行工具kubecfg提交：
./kubecfg -c redisController.json create /replicationControllers
提交完后，通过kubecfg查看replicationController状态：
# ./kubecfg list /replicationControllers
----------
----------
----------
----------
redisController
dockerfile/redis
name=redis
同时，1个pod也将被自动创建出来，即使我们故意删除该pod，replicationController也将保证创建1个新pod。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：89300次
积分：1263
积分：1263
排名：千里之外
原创：46篇
评论：22条
(1)(1)(4)(1)(1)(1)(1)(1)(3)(1)(1)(3)(4)(2)(1)(3)(4)(12)(2)(3)
(window.slotbydup = window.slotbydup || []).push({
id: '4740881',
container: s,
size: '200,200',
display: 'inlay-fix'用户名：结束的伤感
文章数：60
评论数：43
访问量：64856
注册日期：
阅读量：1297
阅读量：3317
阅读量：461274
阅读量：1145713
51CTO推荐博文
一、Kubernetes简介Kubernetes 是Google开源的容器集群管理系统，基于Docker构建一个容器的调度服务，提供资源调度、均衡容灾、服务注册、动态扩缩容等功能套件，利用Kubernetes能方便地管理跨机器运行容器化的应用。而且Kubernetes支持GCE、vShpere、CoreOS、OpenShift、Azure等平台上运行，也可以直接部署在物理主机上。二、Kubernetes架构1. Pod在Kubernetes系统中，调度的最小颗粒不是单纯的容器，而是抽象成一个Pod，Pod是一个可以被建、销毁、调度、管理的最小的部署单元;Pod是kubernetes的最小操作单元，一个Pod可以由一个或多个容器组成;&同一个Pod只能运行在同一个主机上;同一个Pod共享着相同的volumes,network命名空间。2. ReplicationController（RC）RC是用来管理Pod的，每个RC可以由一个或多个的Pod组成，在RC被创建后，系统将会保持RC中的可用Pod的个数与创建RC时定义的Pod个数一致，如果Pod个数小于定义的个数，RC会启动新的Pod，反之则会杀死多余的PRC通过定义的Pod模板被创建，创建后对象叫做Pods(也可以理解为RC)，可以在线的修改Pods的属性，以实现动态缩减/扩展Pods的规模或属性;&RC通过label关联对应的Pods，通过修改Pods的label可以删除对应的Pods&在需要对Pods中的容器进行更新时，RC采用一个一个的替换原则来更新整个Pods中的Pod.3、ServiceServices是Kubernetes最外围的单元，通过虚拟一个访问IP及服务端口，可以访问我们定义好的Pod资源;Service也是Kubernetes的最小操作单元，是真实应用服务的抽象;&Service通常用来将浮动的资源与后端真实提供服务的容器进行关联;&Service对外表现为一个单一的访问接口，外部不需要了解后端的规模与机制。&Service其实是定义在集群中一组运行Pod集合的抽象资源，它提供所有相同的功能。当一个Service资源被创建后，将会分配一个唯一的IP(也叫集群IP)，这个IP地址将存在于Service的整个生命周期，Service一旦被创建，整个IP无法进行修改。Pod可以通过Service进行通信，并且所有的通信将会通过Service自动负载均衡到所有的Pod中的容器。4、LabelLabels是用于区分Pod、Service、Replication Controller的key/value键值对，仅使用在Pod、Service、 Replication Controller之间的关系识别，但对这些单元本身进行操作时得使用name标签;Pod、Service、RC可以有多个label，但是每个label的key只能对应一个整个系统都是通过Label进行关联，得到真正需要操作的目标。5、ProxyProxy不但解决了同一主宿机相同服务端口冲突的问题，还提供了Service转发服务端口对外提供服务的能力，Proxy后端使用了随机、轮循负载均衡算法。三、Kubernetes相关组件Kubernetes主要包括:kubectl、kube-apiserver、kube-controller-manager、kube-scheduler、kube-proxy、kubelet，当然这些并不能组成一个完整的kubernetes系统，整个系统中的信息还需要一个存储介质Etcd，网络服务Flannel(可选)1.Kubectl一个命令行工具，将接收到的命令，格式化后，发送给kube-apiserver，作为对整个平台操作的入口。2.Kube-apiserver作为整个系统的控制入口，以RESTAPI的形式公开。它可以横向扩展在高可用架构中。3.Kube-controller-manager用来执行整个系统中的后台任务，它其实是多个控制进程的合体。大致包括如下:Node Controller & &##负责整个系统中node up或down的状态的响应和通知Replication Controller & &##负责维持Pods中的正常运行的pod的个数Endpoints Controller & & & ##负责维持Pods和Service的关联关系Service Account & Token Controllers & &&##负责为新的命名空间创建默认的账号和API访问Token4.Kube-scheduler & & & & & & &负责监视新创建的Pods任务，下发至未分配的节点运行该任务5.Kube-proxykube-proxy运行在每个节点上，它负责整个网络规则的连接与转发，使kubernetes中的service更加抽象化6.Kubeletkubelet运行在每个节点上，作为整个系统的agent，监视着分配到该节点的Pods任务，(通过apiserver或者本地配置文件)，负责挂载Pods所依赖的卷组，下载Pods的秘钥，运行Pods中的容器(通过docker)，周期获取所有容器的可用状态，通过导出Pod和节点的状态反馈给REST系统7.Pod一组共享上下文的应用程序叫做一个pod，在上下文中，程序也可以应用单独的cgroup隔离。一个pod的模型就是一组运行指定应用的容器环境(逻辑主机)，他可以容纳一个或多个应用程序，但是在一个容器世界里，这表现的相对较耦合。它们会运行在相同的物理主机或虚拟主机上pod中的上下文是结合Linux命令空间来定义的，这里包含:pod namespace(pod中的应用程序可以看到其他的进程)network namespace(应用程序获得相同的IP和端口空间)ipc namespace(pod中应用程序可以使用SystemV IPC或者POSIX消息队列来通信)uts namespace(pod中的应用程序共享主机名)资源共享和通信pod中所有的应用程序使用相同的网络命名空间，应用程序间可以使用localhost来发现其他程序及通信。每一个pod都有一个IP地址，用来和其他物理节点及跨网络的容器进行通信。pod作为部署的最小单位，支持水平扩展和复制.四、kubernetes各组件功能介绍角色 & & & & & & 组件 & & & & & & & & & & & & & & & & & & & 功能Master & & & & apiserver & & & & & & & & & & & & 提供PESTful接口Master & & & & scheduler & & & & & & &负责调度，将Pod分配到Slave节点Master & & controller-manager & & & & & &负责Master的其他功能Master & & & & & etcd & & & & & & & & &存储配置信息，节点信息，pod信息等Slave & & & & & kubelet & & & & & & & & & & 负责管理Pod、容器和容器镜像Slave & & & & & &proxy & & &将访问Service的请求转发给对应的Pod，做一些负载均衡客户端 & & & & &kubectl & & & & & & &命令行工具，向apiserver发起创建Pod等请求五、kubernetes安装1.yum安装#&yum&-y&install&etcd&kubernetes2.升级(覆盖bin文件即可)①升级etcd#&curl&-L&&/coreos/etcd/releases/download/v2.2.3/etcd-v2.2.3-linux-amd64.tar.gz&-o&etcd-v2.2.3-linux-amd64.tar.gz
#&tar&-zxvf&etcd-v2.2.3-linux-amd64.tar.gz&
#&cd&etcd-v2.2.3-linux-amd64
#&cp&etcd*&/bin/
#&etcd&-version
etcd&Version:&2.2.3
Git&SHA:&05b564a
Go&Version:&go1.5.2
Go&OS/Arch:&linux/amd64
#&etcd&&&/var/log/etcd.log&2&&1&&&&&&&&&&&&&&&&&&##启动etcd
#&curl&127.0.0.1:4001/version
{"etcdserver":"2.2.3","etcdcluster":"2.2.0"}
#&&etcdctl&member&list&&&&&&&&&&&&&&&&##查看etcd集群
ce2a822cea30bfca:&name=default&peerURLs=http://localhost:2380,http://localhost:7001&clientURLs=http://localhost:2379,http://localhost:4001②升级kubernetes#&wget&/GoogleCloudPlatform/kubernetes/releases/download/v1.2.0-alpha.5/kubernetes.tar.gz
#&tar&-zxvf&kubernetes.tar.gz
#&cd&kubernetes/server
#&tar&-zxvf&kubernetes-server-linux-amd64.tar.gz
#&cd&kubernetes/server/bin/
#&cp&-a&kubectl&kubelet&kube-controller-manager&kube-scheduler&kube-apiserver&kube-proxy&/usr/bin/a.运行kube-apiserver[systemctl start kube-apiserver]#&kube-apiserver&--address=0.0.0.0&--insecure-port=8080&--service-cluster-ip-range='10.254.0.0/16'&--kubelet_port=10250&--v=0&--logtostderr=false&--log_dir=/var/log/kube&--etcd_servers=http://127.0.0.1:4001&--allow_privileged=false&&
#&kubectl&version
Client&Version:&{Major:"1",&Minor:"2+",&GitVersion:"v1.2.0-alpha.5",&GitCommit:"9c0eab0a",&GitTreeState:"clean"}
Server&Version:&{Major:"1",&Minor:"2+",&GitVersion:"v1.2.0-alpha.5",&GitCommit:"9c0eab0a",&GitTreeState:"clean"}
#&ss&-tlnp|grep&apiserver
LISTEN&&&&&0&&&&&&128&&&&&&&&&&&&&&&&&&&&&&:::6443&&&&&&&&&&&&&&&&&&&&:::*&&&&&&users:(("kube-apiserver",1811,27))
LISTEN&&&&&0&&&&&&128&&&&&&&&&&&&&&&&&&&&&&:::8080&&&&&&&&&&&&&&&&&&&&:::*&&&&&&users:(("kube-apiserver",1811,26))b.运行kube-scheduler[systemctl start kube-scheduler]#&kube-scheduler&--v=0&--logtostderr=false&--log_dir=/var/log/kube&--master='127.0.0.1:8080'&&
#&ss&-tlnp|grep&scheduler
LISTEN&&&&&0&&&&&&128&&&&&&&&&&&&&&&127.0.0.1:10251&&&&&&&&&&&&&&&&&&&&*:*&&&&&&users:(("kube-scheduler",1933,9))c.运行kube-controller-manager[systemctl start kube-controller-manager]#&kube-controller-manager&--v=0&--logtostderr=false&--log_dir=/var/log/kube&&--port=10252&--master=127.0.0.1:8080&&
#&ss&-tlnp|grep&controller
LISTEN&&&&&0&&&&&&128&&&&&&&&&&&&&&&127.0.0.1:10252&&&&&&&&&&&&&&&&&&&&*:*&&&&&&users:(("kube-controller",1880,9))Minion(需先启动docker才能运行kubelet)a.运行kube-proxy[systemctl start kube-proxy]#&kube-proxy&--v=0&--logtostderr=false&--log_dir=/var/log/kube&--master=http://master:8080&&
#&ss&-tlnp|grep&proxy
LISTEN&&&&&0&&&&&&128&&&&&&&&&&&&&&&127.0.0.1:10249&&&&&&&&&&&&&&&&&&&&*:*&&&&&&users:(("kube-proxy",1635,3))
LISTEN&&&&&0&&&&&&128&&&&&&&&&&&&&&&&&&&&&&:::54921&&&&&&&&&&&&&&&&&&&:::*&&&&&&users:(("kube-proxy",1635,7))b.运行kubelet[systemctl start kubelet]#&kubelet&--v=0&--logtostderr=false&--allow-privileged=false&--log_dir=/var/log/kube&--address=0.0.0.0&--port=10250&--register-node=true&--api_servers=mastr:8080&&
#&ss&-tlnp|grep&kubelet
LISTEN&&&&&0&&&&&&128&&&&&&&&&&&&&&&127.0.0.1:10248&&&&&&&&&&&&&&&&&&&&*:*&&&&&&users:(("kubelet",6277,14))
LISTEN&&&&&0&&&&&&128&&&&&&&&&&&&&&&&&&&&&&:::4194&&&&&&&&&&&&&&&&&&&&:::*&&&&&&users:(("kubelet",6277,11))
LISTEN&&&&&0&&&&&&128&&&&&&&&&&&&&&&&&&&&&&:::10250&&&&&&&&&&&&&&&&&&&:::*&&&&&&users:(("kubelet",6277,18))
LISTEN&&&&&0&&&&&&128&&&&&&&&&&&&&&&&&&&&&&:::10255&&&&&&&&&&&&&&&&&&&:::*&&&&&&users:(("kubelet",6277,15))Master#&kubectl&get&nodes&&&&&&&&&&&&&&##查看node清单
NAME&&&&&&&&&&&&&&&&&&&&LABELS&&&&&&&&&&&&&&&&&&&&&&&&&STATUS&&&&AGE
127.0.0.1&&&&&&kubernetes.io/hostname=127.0.0.1&&&&&&&NotReady&&&23d
localhost.localdomain&&&kubernetes.io/hostname=localhost.localdomain&&&NotReady&&&21d
minion&&&&&&&&kubernetes.io/hostname=minion&&&&&&&&&&&NotReady&&&21d
#&kubectl&get&pods&&&&&&&&&&&&&&&&##查看pods清单
NAME&&&&&&READY&&&&&STATUS&&&&RESTARTS&&&AGE
#&kubectl&get&services&&&&&&&&&&&&&##查看service清单
NAME&&&&&&&&&CLUSTER_IP&&&EXTERNAL_IP&&&PORT(S)&&&SELECTOR&&&AGE
kubernetes&&&10.254.0.1&&&&none&&&&&&&&&443/TCP&&&&none&&&&&&4d
#&kubectl&get&replicationcontrollers&&&##查看replicationControllers清单
CONTROLLER&&&CONTAINER(S)&&&IMAGE(S)&&&SELECTOR&&&REPLICAS本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)}