1. 名词概念
- cluster：Cluster是计算、存储和网络资源的汇合，Kubernetes利用这些资源运行各种基于容器的利用。
- master：Master是Cluster的大脑，它的主要职责是调度，即决定将利用放在哪里运行。为了实现高可用，能够运行多个Master。
- node：Node的职责是运行容器利用。Node由Master治理，Node负责监控并汇报容器的状态，同时依据Master的要求治理容器的生命周期。
- pod：Pod是Kubernetes的最小工作单元。每个Pod蕴含一个或多个容器。Pod中的容器会作为一个整体被Master调度到一个Node上运行。
- controller：Kubernetes通常不会间接创立Pod，而是通过Controller来治理Pod的。Controller中定义了Pod的部署个性，比方有几个正本、在什么样的Node上运行等。为了满足不同的业务场景，Kubernetes提供了多种Controller，包含Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job等。
- service：Kubernetes Service定义了外界拜访一组特定Pod的形式。Service有本人的IP和端口，Service为Pod提供了负载平衡。Deployment能够部署多个正本，每个Pod都有本人的IP，Service为外界拜访这些正本提供了解决形式。
- namespace：Namespace能够将一个物理的Cluster逻辑上划分成多个虚构Cluster，每个Cluster就是一个Namespace。不同Namespace里的资源是齐全隔离的。Kubernetes默认创立了两个Namespace：（1）default：创立资源时如果不指定，将被放到这个Namespace中。（2）kubesystem：Kubernetes本人创立的系统资源将放到这个Namespace中。
- kubectl：kubectl是Kubernetes集群的命令行工具，通过kubectl可能对集群自身进行治理，并可能在集群上进行容器化利用的装置部署。
- kubelet：kubelet 是运行在每个节点上的次要的“节点代理”，每个节点都会启动 kubelet过程，用来解决 Master 节点下发到本节点的工作，依照 PodSpec 形容来治理Pod 和其中的容器。kubelet的次要性能有：（1）pod治理，定期从所监听的数据源获取节点上 pod/container的冀望状态并治理执行。（2）容器健康检查，查看容器是否失常运行，如果容器运行出错依照重启策略解决。（3）资源监控，监控所在节点的资源应用状况，并定时向 master 报告，晓得整个集群所有节点的资源状况，对于 pod 的调度和失常运行至关重要。
2. 架构
k8s集群Cluster是计算、存储和网络资源的汇合，Kubernetes利用这些资源运行各种基于容器的利用。
2.1. master构造
Master是KubernetesCluster的大脑，运行着的Daemon服务包含kubeapiserver、kubescheduler、kubecontrollermanager、etcd和Pod网络。
2.1.1. api server
k8s api server提供了k8s各类资源对象（pod,RC,Service等）的增删改查及watch等http rest接口，是整个零碎的数据总线和数据中心。像平时执行kubectl，理论是会将对资源的申请命令传递给api server。包含市场上有很多底层基于k8s的容器治理产品，都对api server的rest接口进行肯定封装，从而对k8s进行操作。
kubernetes api server的性能：
- 提供了集群治理的REST API接口(包含认证受权、数据校验以及集群状态变更)；
- 提供其余模块之间的数据交互和通信的枢纽（其余模块通过 api server查问或批改数据，只有 api server才间接操作etcd）;
- 是资源配额管制的入口；
- 领有齐备的集群平安机制。
2.1.2. scheduler
Scheduler负责决定将Pod放在哪个Node上运行。Scheduler在调度时会充分考虑Cluster的拓扑构造，以后各个节点的负载，以及利用对高可用、性能、数据亲和性的需要。
2.1.3. controller manager
ControllerManager负责管理Cluster各种资源，保障资源处于预期的状态。
ControllerManager由多种controller组成，包含replicationcontroller、endpointscontroller、namespacecontroller、serviceaccountscontroller等。不同的controller治理不同的资源。例如，replicationcontroller治理Deployment、StatefulSet、DaemonSet的生命周期，namespacecontroller治理Namespace资源。
2.1.4. etcd
etcd负责保留KubernetesCluster的配置信息和各种资源的状态信息。当数据发生变化时，etcd会疾速地告诉Kubernetes相干组件。
2.2. node构造
Node是Pod运行的中央，Kubernetes反对Docker、rkt等容器Runtime。Node上运行的Kubernetes组件有kubelet、kubeproxy和Pod网络。
2.2.1. kubelet
kubelet是Node的agent，当Scheduler确定在某个Node上运行Pod后，会将Pod的具体配置信息（image、volume等）发送给该节点的kubelet，kubelet依据这些信息创立和运行容器，并向Master报告运行状态。
2.2.2. kube-proxy
service在逻辑上代表了后端的多个Pod，外界通过service拜访Pod。service接管到的申请是如何转发到Pod的呢？这就是kubeproxy要实现的工作。
每个Node都会运行kubeproxy服务，它负责将拜访service的TCP/UPD数据流转发到后端的容器。如果有多个正本，kubeproxy会实现负载平衡。
3. 部署服务
k8s上的资源编排命令，都通过kubectl来执行，kubectl的命令有很多，这里侧重于解说两种部署形式。一种形式，通过kubectl的命令行来部署（kebectl run --optional）；另一种形式，则通过启用残缺的yaml文件来部署和编排服务。
第一种形式更疾速便捷，但第二种形式更正式标准，上面都会做简略介绍。
3.1. kubectl命令
kubectl 创建对象
$ kubectl create -f ./my-manifest.yaml #创立资源$ kubectl create -f ./my1.yaml -f ./my2.yaml #应用多个文件创建资源$ kubectl create -f ./dir #应用目录下的所有清单文件（yaml）来创立资源$ kubectl create -f https://git.io/vPieo #应用url创立资源$ kubectl run nginx --image=nginx #启动一个nginx实例$ kubectl explain pods #获取pod和svc的文档kubectl 显示和查找资源
$ kubectl get pods --all-namespaces #列出所有namespace中的pod，也能够是services、deployment等$ kubectl get pods -o wide #列出pod并显示详细信息$ kubectl get deployment my-dep #列出指定daployment$ kubectl get pods --include-uninitialized #列出该namespace中的所有pod，包含未初始化的应用具体输入来形容命令
$ kubectl describe nodes <my-node IP or name> #查看node节点信息$ kubectl describe pods <my-pod> #查看pod详细信息$ kubectl get services --sort-by=.metadata.name --all-namespaces #l列出所有service并按名称排序kubectl编辑资源
$ kubectl -n codeus edit svc/c #编辑codeus命名空间下名称为c的servicekubectl Scale 资源
$ kubectl scale --replicas=3 rs/foo #扩展名称为foo的资源到3个，是否应用rs取决于yaml中的编写kubectl 删除资源
$ kubectl delete deployment <name> #删除指定deployment，此办法还能够删除service等$ kubectl delete -f xxx.yaml #通过创立此pod的yaml文件删除podkubectl 与运行中的pod交互
$ kubectl -n <namespaces> logs my-podname #查看pod日志， -f 继续查看$ kubectl port-forward my-podname 5000:6000 #转发pod中的6000端口到本地的5000端口$ kubectl exec my-podname -- ls / #在已存在的容器中执行命令3.2. run部署
根底部署的命令是 kubectl run：
kubectl run NAME --image=image [--env="key=value"] [--port=port] [--replicas=replicas] [--dry-run=bool] [--overrides=inline-json] [--command] -- [COMMAND] [args...]例如，部署一个nginx容器，启动5个正本：
kubectl run nginx --image=nginx --replicas=5能够看到，次要决定容器部署的编排环境的，取决于 --前面的参数，具体的参数对照表如下：
| 参数名称 | 默认值 | 形容 | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| attach | false | If true, wait for the Pod to start running, and then attach to the Pod as if 'kubectl attach ...' were called. Default false, unless '-i/--stdin' is set, in which case the default is true. With '--restart=Never' the exit code of the container process is returned. | |||||||||
| command | false | If true and extra arguments are present, use them as the 'command' field in the container, rather than the 'args' field which is the default. | |||||||||
| dry-run | false | If true, only print the object that would be sent, without sending it. | |||||||||
| env | [] | Environment variables to set in the container | |||||||||
| expose | false | If true, a public, external service is created for the container(s) which are run | |||||||||
| hostport | -1 | The host port mapping for the container port. To demonstrate a single-machine container. | |||||||||
| image | The image for the container to run. | ||||||||||
| image-pull-policy | The image pull policy for the container. If left empty, this value will not be specified by the client and defaulted by the server | ||||||||||
| include-extended-apis | true | If true, include definitions of new APIs via calls to the API server. [default true] | |||||||||
| labels | Labels to apply to the pod(s). | ||||||||||
| leave-stdin-open | false | If the pod is started in interactive mode or with stdin, leave stdin open after the first attach completes. By default, stdin will be closed after the first attach completes. | |||||||||
| limits | The resource requirement limits for this container. For example, 'cpu=200m,memory=512Mi'. Note that server side components may assign limits depending on the server configuration, such as limit ranges. | ||||||||||
| no-headers | false | When using the default or custom-column output format, don't print headers (default print headers). | |||||||||
| output | Output format. One of: json | yaml | wide | name | custom-columns=... | custom-columns-file=... | go-template=... | go-template-file=... | jsonpath=... | jsonpath-file=... See custom columns [http://kubernetes.io/docs/use...], golang template [http://golang.org/pkg/text/te...] and jsonpath template [http://kubernetes.io/docs/use...]. | |
| pod-running-timeout | 1m0s | The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running | |||||||||
| port | The port that this container exposes. If --expose is true, this is also the port used by the service that is created. | ||||||||||
| replicas | 1 | Number of replicas to create for this container. Default is 1. | |||||||||
| requests | The resource requirement requests for this container. For example, 'cpu=100m,memory=256Mi'. Note that server side components may assign requests depending on the server configuration, such as limit ranges. | ||||||||||
| restart | Always | The restart policy for this Pod. Legal values [Always, OnFailure, Never]. If set to 'Always' a deployment is created, if set to 'OnFailure' a job is created, if set to 'Never', a regular pod is created. For the latter two --replicas must be 1. Default 'Always', for CronJobs Never. | |||||||||
| rm | false | If true, delete resources created in this command for attached containers. | |||||||||
| save-config | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | |||||||||
| schedule | A schedule in the Cron format the job should be run with. | ||||||||||
| show-all | false | When printing, show all resources (default hide terminated pods.) | |||||||||
| show-labels | false | When printing, show all labels as the last column (default hide labels column) | |||||||||
| sort-by | If non-empty, sort list types using this field specification. The field specification is expressed as a JSONPath expression (e.g. '{.metadata.name}'). The field in the API resource specified by this JSONPath expression must be an integer or a string. | ||||||||||
| stdin | false | Keep stdin open on the container(s) in the pod, even if nothing is attached. | |||||||||
| template | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates [http://golang.org/pkg/text/te...]. |
3.3. yaml部署
能够将构建容器的所有配置信息写在yaml文件上，而后通过yaml文件来创立。原则上来说有create和apply两种形式，不过如上面的比照，倡议都用apply。
- kubectl create -f xxx.yaml （不倡议应用，无奈更新，必须先delete）
- kubectl apply -f xxx.yaml （创立+更新，能够重复使用）
上面重点关注 yaml文件的编写，一个根底的yaml部署文件次要蕴含Deployment和Service两局部。
后面说过了，k8s通过各种Controller来治理pod的生命周期，Controller有很多种，其中就包含Deployment。而针对多正本的pod，就须要Service来提供外界对立的拜访形式。
---apiVersion: apps/v1kind: Deploymentmetadata:name: nginx-deploynamespace: demo-spacespec:replicas: 2selector:matchLabels:app: k8s-demo-nginxtemplate:metadata:labels:app: k8s-demo-nginxspec:containers:- name: nginximage: docker.io/nginxresources:limits:cpu: "0.3"memory: "300Mi"requests:cpu: "0.2"memory: "200Mi"ports:- containerPort: 80---apiVersion: v1kind: Servicemetadata:name: k8s-nginxnamespace: demo-spacespec:type: NodePortports:- port: 80targetPort: 80 nodePort: 10280protocol: TCPselector:app: k8s-demo-nginx名词解释：
- apiVersion：以后配置格局的版本。
- kind：定义了要创立的资源类型，这里有Deployment和Service。
- metadate：是该资源的元数据，其中name是必须的元数据项；namespace指明资源创立所处的命名空间，如果不填，默认创立中default命名空间下。
- spec：定义该资源的规格阐明。
- replicas：正本数量，默认为1。
- template：定义了pod的创立模版。
- template.metadate：定义了pod的元数据，至多要定义一个label，label的key和value能够任意指定。
- selector.matchLabels：和pod元数据中的label对应，筛选匹配的pod做对立治理。
- template.spec.resources：做pod的资源限度。
requests定义了容器运行时起码须要的资源，limits定义了容器运行时最多能调配的资源。
3.4. 各种Port比照
后面示例的yaml配置中，定义了很多端口（containerPort、targetPort、port、nodePort），上面解释一下它们的不同作用：
1、containerPort
定义Pod的端口，在Deployment yaml中，申明Pod容器须要裸露的端口。
2、targetPort
也是定义Pod的端口，在Service yaml中，从port和nodePort上到来的数据最终通过kube-proxy流入到后端pod的targetPort上进入容器。
3、port
定义Service的端口，<cluster ip>:port 是提供给集群外部客户拜访service的入口。集群外部拜访该地址，是会通过kube-proxy再流入pod。
4、nodePort
定义Service的端口，<nodeIP>:nodePort 是提供给集群内部客户拜访service的入口。集群内部拜访该地址，是会通过kube-proxy再流入pod。
启用nodePort内部端口映射，须要先配置spec.type=nodePort，如果不指定nodePort的端口后，服务器会主动调配一个端口。