关于kubernetes:Kubernetes笔记

1. 名词概念

1. cluster：Cluster 是计算、存储和网络资源的汇合，Kubernetes 利用这些资源运行各种基于容器的利用。
2. master：Master 是 Cluster 的大脑，它的主要职责是调度，即决定将利用放在哪里运行。为了实现高可用，能够运行多个 Master。
3. node：Node 的职责是运行容器利用。Node 由 Master 治理，Node 负责监控并汇报容器的状态，同时依据 Master 的要求治理容器的生命周期。
4. pod：Pod 是 Kubernetes 的最小工作单元。每个 Pod 蕴含一个或多个容器。Pod 中的容器会作为一个整体被 Master 调度到一个 Node 上运行。
5. controller：Kubernetes 通常不会间接创立 Pod，而是通过 Controller 来治理 Pod 的。Controller 中定义了 Pod 的部署个性，比方有几个正本、在什么样的 Node 上运行等。为了满足不同的业务场景，Kubernetes 提供了多种 Controller，包含 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等。
6. service：Kubernetes Service 定义了外界拜访一组特定 Pod 的形式。Service 有本人的 IP 和端口，Service 为 Pod 提供了负载平衡。Deployment 能够部署多个正本，每个 Pod 都有本人的 IP，Service 为外界拜访这些正本提供了解决形式。
7. namespace：Namespace 能够将一个物理的 Cluster 逻辑上划分成多个虚构 Cluster，每个 Cluster 就是一个 Namespace。不同 Namespace 里的资源是齐全隔离的。Kubernetes 默认创立了两个 Namespace：（1）default：创立资源时如果不指定，将被放到这个 Namespace 中。（2）kubesystem：Kubernetes 本人创立的系统资源将放到这个 Namespace 中。
8. kubectl：kubectl 是 Kubernetes 集群的命令行工具，通过 kubectl 可能对集群自身进行治理，并可能在集群上进行容器化利用的装置部署。
9. 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 的 service

kubectl 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 文件删除 pod

kubectl 与运行中的 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

能够看到，次要决定容器部署的编排环境的，取决于 --前面的参数，具体的参数对照表如下：

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/v1

kind: Deployment

metadata:

name: nginx-deploy

namespace: demo-space

spec:

replicas: 2

selector:

matchLabels:

app: k8s-demo-nginx

template:

metadata:

labels:

app: k8s-demo-nginx

spec:

containers:

- name: nginx

image: docker.io/nginx

resources:

limits:

cpu: "0.3"

memory: "300Mi"

requests:

cpu: "0.2"

memory: "200Mi"

ports:

- containerPort: 80

---

apiVersion: v1

kind: Service

metadata:

name: k8s-nginx

namespace: demo-space

spec:

type: NodePort

ports:

- port: 80

targetPort: 80 

nodePort: 10280

protocol: TCP

selector:

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 的端口后，服务器会主动调配一个端口。