陈述式资源办理方法：
- kubernetes集群办理集群资源的仅有入口是经过相应的方法调用apiserver的接口
- kubectl是官方的CLI指令行东西，用于与 apiserver 进行通讯，将用户在指令行输入的指令，组织并转化为 apiserver能识别的信息，然后完成办理 k8s 各种资源的一种有效途径
- kubectl 的指令大全
- kubectl –help
- k8s中文文档:docs.kubernetes.org.cn/683.html
- 对资源的增、删、查操作比较方便，但对改的操作就不容易了
检查版别信息
kubectl vsrsion
检查资源对象简写
kubectl api-resources
检查集群信息
kubectl cluster-info
运用less东西检查较长的文件信息
kubectl cluster-info dump | less
装备kubectl主动补全
vim /etc/bashrc
source <(kubectl completion bash)
node节点检查日志
journalctl -u kubelet -f
基本信息检查
kubectl get <resource> [-o wide|json|yaml] [-n namespace]
获取资源的相关信息，-n 指定命名空间 -o指定输出格局
resource可所以详细资源称号，如pod nginx-xxxx
也可所以资源类型，如pod 或许all（仅展示几种中心资源，并不完好）
--all-namespaces 或-A： 表明显现一切命名空间
--show-labels:显现一切标签
-l app:仅显现标签为app的资源
-l app=nginx:仅显现包含app标签，却值为nginx的资源
检查pod资源
kubectl get pods
检查kube-system资源
kubectl get pods -n kube-system
检查一切pod的信息
kubectl get pods -n kube-system -o wide
检查单个pod的信息
all 显现中心资源
检查 master 节点状况
kubectl get componentstatuses
kubectl get cs
检查命名空间
kubectl get namespaces
kubectl get ns
命名空间的作用：用于答应不同 命名空间 的 不同类型 的资源 重名的
创立命名空间app
kubectl create ns app
删去命名空间app
kubectl delete namespaces app
在命名空间kube-public 创立副本控制器（deployment）来发动pod（Nginx-aa）
kubectl create deployment nginx-aa --image=nginx -n kube-public
描绘某个资源的详细信息
kubectl describe deployment nginx-aa -n kube-public
假如检查资源为非running状况，能够经过describe去检查相关的事件
kubectl describe pods nginx-aa-c8947f894-fqnkp -n kube-public
检查命名空间kube-public中的pod信息
kubectl get pods -n kube-public
kubectl exec 能够跨主机登录容器，docker exec只能在容器地点的主机上登录
kubectl exec -it nginx-aa-66b8d4497f-fxhpd bash -n kube-public
删去（重启）pod资源，因为存在deployment/rc之类的副本控制器，删去pod也会从头拉起来
kubectl delete pod nginx-aa-c8947f894-z52fz -n kube-public
若pod无法删去，总是处于terminate状况，则要强行删去pod
kubectl delete pod <pod-name> -n <namesoace> --force --grace-period=0
grace-period表明过渡存活期，默认30S，在删去pod之前答应pod渐渐中止其上的容器进程，然后优雅退出，0表明当即中止pod
扩缩容
扩容
kubectl scale deployment nginx-aa --replicas=2 -n kube-public
缩容
kubectl scale deployment nginx-aa --replicas=1 -n kube-public
删去副本控制器
kubectl delete deployment nginx-aa -n kube-public
项目的生命周期
创立-->发布-->更新-->回滚-->删去
- 创立kubectl create 指令
- 创立并运转一个或多个容器镜像
- 创立一个deployment或job来办理容器
发动Nginx实例，露出容器端口80，设置副本数3
kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3
将资源露出为新的service
kubectl expose --help
为deployment的Nginx创立service，并经过service的80端口转发至容器的80端口上，service的称号为Nginx-service，类型为NodePort
kubectl expose deployment nginx --target-port=80 --name=nginx-service --type=NodePort
kubernetes之所以需求service，一方面是因为pod的IP不是固定的（Pod肯能会重建），另一方面则是因为一组pod实例之间总会有负载均衡的需求，service经过label selector完成的对一组pod的拜访，关于容器运用而言，kubernates供给了基于VIP（虚拟ip）的网桥的方法拜访service，再由service重定向到相应的pod。
service的type类型
-
ClusterIP:供给了集群内部的虚拟IP以供pod拜访（service默认类型）
-
NodePort:在每个Node上翻开一个端口供外部拜访，kubernetes将会在每个node上翻开一个端口而且在每个node的端口上都相同的，经过NodeIP：NodePort的方法kubernates集群外部的程序能够拜访service
每个端口只能是一种服务，端口的规模只能是30000-32767
-
LoadBalancer:经过设置LoaBalancer映射到云服务商供给的LoaBalancer地址，这种方法用于在公有云服务供给商的云平台上设置service的场景。经过外部的负载均衡器来拜访，通常在云平台布置LoaBalancer还需求额外的费用，在service提交后，kubernetes就会调用CloudPorvider在公有云上为你创立一个负载均衡服务，而且把被署理的pod的IP地址装备给负载均衡服务的后端
-
externalName:将service称号映射到一个DNS域名上，相当于DNS服务的CNAME记录，用于让pod去拜访集群外部的资源，它本身没有绑定任何的资源
检查pod网络状况详细信息和service露出的端口
kubectl get pods,svc -o wide
检查关联后端的节点
kubectl get endpoints
检查service的描绘信息
kubectl describe svc nginx
在node01节点上操作，检查负载均衡的端口
yum -y install ipvsadm
在master操作，检查拜访日志
- 更新kubectl set
更改现有运用资源一些信息
kubectl set --help
获取修改模板
kubectl set image --help
检查当时Nginx的版别号
curl -I 10.96.106.64
将Nginx版别更新为1.16版别
kubectl set image deployments nginx nginx=nginx:1.16
处于动态监听pod状况，因为运用的是翻滚更新方法，所以先生成一个新的pod，然后删去一个旧的pod，往后依次类推
kubectl get pods -w
再看更新好后的pod的ip会改动
kubectl get pods -o wide
再看Nginx的版别号
curl -I 10.244.2.12
- 回滚kubectl rollout
对资源进行回滚办理
kubectl rollout -h
检查历史版别
kubectl rollout history deployment/nginx
履行回滚到上一个版别
kubectl rollout undo deployment/nginx
履行回滚到指定版别
kubectl rollout undo deployment/nginx --to-revision=2
检查回滚状况
kubectl rollout status deployment/nginx
- 删去kubectl delete
删去副本控制器
kubectl delete deployments/nginx
删去service
kubectl delete svc/nginx-service
三种常用的项目发布方法
常见三种发布方法分别为：蓝绿发布，灰度发布和翻滚发布
蓝绿发布
概念界说：蓝绿发布是一种以最小的停机时刻做服务晋级的战略。需求保护的两个版别的环境分别称为“蓝环境”和“绿环境”。一般当时出产流量指向环境为绿环境，而在蓝环境上布置新版别，短时刻内作为测试环境。
发布流程：首先将一半的服务流量从负载均衡列表中移除，而且更新服务版别，验证新版别没有问题后，将出产流量指向蓝环境，然后关于老版别的绿环境进行版别晋级，最终将一切服务流量加回负载均衡。
特色
- 假如出问题，影响规模较大；
- 发布战略简略；
- 用户无感知，滑润过渡；
- 晋级/回滚速度快。
缺陷
- 需求准备正常业务运用资源的两倍以上服务器，避免晋级期间单组无法承载业务突发；
- 短时刻内糟蹋必定资源本钱；
- 基础设施无改动，增大晋级稳定性。
蓝绿发布在前期物理服务器年代，还是比较贵重的，因为云核算遍及，本钱也大大下降。
灰度发布（金丝雀发布）
概念界说：灰度发布归于增量发布，新老版别一起为用户供给服务。灰度发布的首要目的是确保体系的可用性。每一次的线上改变都无法确保体系100%的无bug，所以改变后要在线上小规模验证，等没问题再全面放开。而金丝雀发布是灰度发布的一种完成。
发布流程：在现有环境中布置少数服务的新版别(金丝雀)，布置完成后，对线上流量进行监测，假如没有问题就对老版别服务进行全量晋级。
特色
- 确保全体体系稳定性，在初始灰度的时候就能够发现、调整问题，影响规模可控；
- 新功能逐渐评估功能，稳定性和健康状况，假如出问题影响规模很小，相对用户体验也少；
- 用户无感知，滑润过渡。
缺陷
- 主动化要求高
翻滚发布
翻滚发布便是刚刚咱们在k8s中运用的项目服务更新方法。翻滚发布是指每次只晋级一个或多个服务，晋级完成后加入出产环境，不断履行这个进程，直到集群中的全部旧版别晋级新版别。
特色
- 用户无感知，滑润过渡；
- 节省资源。
缺陷
- 布置时刻慢，取决于每阶段更新时刻；
- 发布战略较杂乱；
- 无法确认OK的环境，不易回滚。
三种方法的对比总结
- 蓝绿发布：两套环境替换晋级，旧版别保存必定时刻便于回滚。
- 灰度发布：根据比例将老版别晋级，例如80%用户拜访是老版别，20%用户拜访是新版别。
- 翻滚发布：按批次中止老版别实例，发动新版别实例。
金丝雀发布的完成
Deployment控制器支持自界说控制更新进程中的翻滚节奏，如“暂停(pause)”或“持续(resume)”更新操作。比方等候第一批新的Pod资源创立完成后当即暂停更新进程，此刻，仅存在一部分新版别的运用，主体部分还是旧的版别。然后，再挑选一小部分的用户请求路由到新版别的Pod运用，持续调查能否稳定地按希望的方法运转。确认没问题之后再持续完成余下的Pod资源翻滚更新，否则当即回滚更新操作。这便是所谓的金丝雀发布。
- 更新deployment的版别，并装备暂停deployment
kubectl set image deployment/nginx nginx=nginx1.14 && kubectl rollout pause deployment/nginx
kubectl rollout status deployment/nginx #调查更新状况
- 监控更新的进程，能够看到已经新增了一个资源，可是并未按照预期的状况去删去一个旧的资源，便是因为运用了pause暂停指令
kubectl get pods -w
curl [-I] 10.244.1.17
- 确保更新的pod没问题了，持续更新
kubectl rollout resume deployment/nginx
- 检查最终更新的情况
kubectl get pods -w
curl [-I] 10.244.1.17
假如对第2次或许往后的更新仍然保存测试的主意，能够采用再更新一部分暂停的方法： kubectl rollout resume deployment nginx && kubectl rollout pause deployment nginx
总结
陈述式
kubectl create <资源类型> <资源称号> -n <命名空间> [选项...kubectl delete <资源类型> <资源称号> -n <命名空间> [--force --grace-period=0]
kubectl get <资源类型> [资源称号] -n <命名空间> -o wide|yaml|json
检查一切命名空间 -A | --all-namespaces --show-labels
-l 标签[=值]
kubectl describe <资源类型> <资源称号> -n <命名空间>
kubectl exec -it <pod资源称号> -n <命名空间> [-c 容器名] [-- 指令]
kubectl scale <deployment|statefulset> <资源称号> -n <命名空间> --replicas=N
service类型
- ClusterIp: 默认的service资源的类型，供给clusterIP 供k8s集群内部拜访
- NodePort: 在每个Node节点上开启一个端口，k8s集群表里的用户能够经过 Node 节点的IP 和 NodePort 即可拜访到service以及关联的相关pod
- LoadBalancer: 运用公有云的LB服务和service做映射，使得用户运用公有云的LB服务的IP地址即可拜访到service以及关联的相关pod
- ExternalName：相当于给一个域名做别名，pod能够经过这个service拜访集群外部的资源
service 和pod 的端口
- por : service 的ClusterIP 所运用的端口
- nodePort ：NodePort类型的service所界说的 在每个Node节点上开启的端口（默认的端口规模30000-32767）
- targetPort：以上port或nodeport 所要转发到的后端pod的端口号
pod里边有一个containePort：后端pod的容器所运用的端口号
k8s集群内部 http://ClusterIP:por -> PodIP:containerPort k8s集群外部 http://NodeIP：NodePort -> PodIP:containerPort
kubectl create <pod控制器资源> <资源称号> --image=镜像 --replicas=副本数 port=容器端口
kubectl expose <pod控制器资源> <资源称号> --name=svc资源称号 --port=ClusterIP的端口 --target-port=容器端口 --type=service类型
kubectl set image <资源类型> <资源称号> 容器=镜像名
kubectl rollout undo [--to-revision=N]
kubectl delete <资源类型> <资源称号>
kubectl describe <资源类型> <资源称号>
kubectl logs <资源类型> <资源称号> [-c 容器名]
发布战略：
蓝绿发布 翻滚发布 灰度发布（金丝雀发布）
