# docker run  --name hello-pod alpine  是跑一个容器，容器的粒度有点小

kubectl run  hello-pod --image=alpine #跑一个Pod。Pod里面其实也是容器

 
kubectl get pod  #以前的docker ps -a

## 所有kubectl在master节点运行，把命令请求发给api-server。api-server一系列处理
##  master只负责调度，而worker node才是真正部署应用的。

docker是每一个worker节点的运行时环境

kubelet负责控制所有容器的启动停止，保证节点工作正常，已经帮助节点交互master

master节点的关键组件：

kubelet（监工）：所有节点必备的，控制这个节点所有pod的生命周期以及与api-server交互等工作
kube-api-server：负责接收所有请求，集群内对集群的任何修改都是通过命令行、ui把请求发给api-server才能执行的。api-server是整个集群操作对内、对外的唯一入口。不包含我们后来部署应用暴露端口的方式
kube-proxy：整个节点的网络流量负责
cri：都有容器运行时环境

worker节点：

kubelet（监工）：所有节点必备的，控制这个节点所有pod的生命周期以及与api-server交互等工作
kube-proxy：整个节点的网络流量负责
cri：都有容器运行时环境

二、部署一个应用

创建一次部署工作(自愈机制)

kubectl create deploy xxxxxx ：命令行会给api-server发送要部署xxx的请求
api-server把这个请求保存到etcd

# kubectl create 帮我们创建k8s集群中的一些对象
kubectl create --help
kubectl create deployment 这次部署的名字 --image=应用的镜像
#Create a deployment named  my-nginx that runs the nginx image
kubectl create deployment my-nginx --image=nginx

##最终在一个机器上有pod、这个pod其实本质里面就是一个容器
k8s_nginx_my-nginx-6b74b79f57-snlr4_default_dbeac79e-1ce9-42c9-bc59-c8ca0412674b_0
### k8s_镜像(nginx)_pod名(my-nginx-6b74b79f57-snlr4)_容器名(default_dbeac79e-1ce9-42c9-bc59-c8ca0412674b_0)

# Create a deployment with command
kubectl create deployment my-nginx --image=nginx -- date

# Create a deployment named my-nginx that runs the nginx image with 3 replicas.
kubectl create deployment my-nginx --image=nginx --replicas=3

# Create a deployment named my-nginx that runs the nginx image and expose port 80.
kubectl create deployment my-nginx --image=nginx --port=80

Deployment（部署）

在k8s中，通过发布 Deployment，可以创建应用程序 (docker image) 的实例 (docker container)，这个实例会被包含在称为 Pod 的概念中，Pod 是 k8s 中最小可管理单元。

在 k8s 集群中发布 Deployment 后，Deployment 将指示 k8s 如何创建和更新应用程序的实例，master 节点将应用程序实例调度到集群中的具体的节点上。

创建应用程序实例后，Kubernetes Deployment Controller 会持续监控这些实例。如果运行实例的 worker 节点关机或被删除，则 Kubernetes Deployment Controller 将在群集中资源最优的另一个 worker 节点上重新创建一个新的实例。这提供了一种自我修复机制来解决机器故障或维护问题。

在容器编排之前的时代，各种安装脚本通常用于启动应用程序，但是不能够使应用程序从机器故障中恢复。通过创建应用程序实例并确保它们在集群节点中的运行实例个数，Kubernetes Deployment 提供了一种完全不同的方式来管理应用程序。

Deployment 处于 master 节点上，通过发布 Deployment，master 节点会选择合适的 worker 节点创建 Container（即图中的正方体），Container 会被包含在 Pod （即蓝色圆圈）里。

自愈：针对使用Deployment等部署的应用。

kubectl run ：直接启动一个pod；不会产生一次部署信息。所以删除就没

kubectl create deploy： 启动一个Pod，以及记录这次部署信息。所以，这个pod即使挂了，这次部署信息有，就会强制同步到这次部署信息期望的最终结果；kubectl get deploy,pod 都有内容

三、应用程序探索

了解Kubernetes Pods（容器组）
了解Kubernetes Nodes（节点）
排查故障

创建 Deployment 后，k8s创建了一个 Pod（容器组） 来放置应用程序实例（container 容器）。

1、了解Pod

Pod （容器组） 是一个k8s中一个抽象的概念，用于存放一组 container（可包含一个或多个 container 容器，即图上正方体)，以及这些 container （容器）的一些共享资源。这些资源包括：

共享存储，称为卷(Volumes)，即图上紫色圆柱
网络，每个 Pod（容器组）在集群中有个唯一的 IP，pod（容器组）中的 container（容器）共享该IP地址
container（容器）的基本信息，例如容器的镜像版本，对外暴露的端口等

Pod（容器组）是 k8s 集群上的最基本的单元。当我们在 k8s 上创建 Deployment 时，会在集群上创建包含容器的 Pod (而不是直接创建容器)。每个Pod都与运行它的 worker 节点（Node）绑定，并保持在那里直到终止或被删除。如果节点（Node）发生故障，则会在群集中的其他可用节点（Node）上运行相同的 Pod（从同样的镜像创建 Container，使用同样的配置，IP 地址不同，Pod 名字不同）。

TIP

重要：

Pod 是一组容器（可包含一个或多个应用程序容器），以及共享存储（卷 Volumes）、IP 地址和有关如何运行容器的信息。

如果多个容器紧密耦合并且需要共享磁盘等资源，则他们应该被部署在同一个Pod（容器组）中。

2、了解Node

Pod（容器组）总是在 Node（节点） 上运行。Node（节点）是 kubernetes 集群中的计算机，可以是虚拟机或物理机。每个 Node（节点）都由 master 管理。一个 Node（节点）可以有多个Pod（容器组），kubernetes master 会根据每个 Node（节点）上可用资源的情况，自动调度 Pod（容器组）到最佳的 Node（节点）上。

每个 Kubernetes Node（节点）至少运行：

Kubelet，负责 master 节点和 worker 节点之间通信的进程；管理 Pod（容器组）和 Pod（容器组）内运行的 Container（容器）。
kube-proxy，负责进行流量转发
容器运行环境（如Docker）负责下载镜像、创建和运行容器等。

Kubelet启动的Pod每个都有Ip，全集群任意位置均可访问

kubeadm init \\
--apiserver-advertise-address=10.170.11.8 \\
--image-repository registry.cn-hangzhou.aliyuncs.com/lanson_k8s_images \\
--kubernetes-version v1.21.0 \\
--service-cidr=10.96.0.0/16 \\
--pod-network-cidr=192.168.0.0/16

--pod-network-cidr=192.168.0.0/16：pod 的ip范围

calico：网络组件:
【扁平化网络】

3、故障排除

kubectl get - 显示资源列表

# kubectl get 资源类型

#获取类型为Deployment的资源列表
kubectl get deployments

#获取类型为Pod的资源列表
kubectl get pods

#获取类型为Node的资源列表
kubectl get nodes

# 查看所有名称空间的 Deployment
kubectl get deployments -A
kubectl get deployments --all-namespaces
# 查看 kube-system 名称空间的 Deployment
kubectl get deployments -n kube-system

#####并不是所有的对象都在名称空间中

# 在名称空间里
kubectl api-resources --namespaced=true

# 不在名称空间里
kubectl api-resources --namespaced=false

kubectl describe - 显示有关资源的详细信息

# kubectl describe 资源类型 资源名称

#查看名称为nginx-XXXXXX的Pod的信息
kubectl describe pod nginx-XXXXXX	

#查看名称为nginx的Deployment的信息
kubectl describe deployment my-nginx

kubectl logs - 查看pod中的容器的打印日志（和命令docker logs 类似）

# kubectl logs Pod名称

#查看名称为nginx-pod-XXXXXXX的Pod内的容器打印的日志
#本案例中的 nginx-pod 没有输出日志，所以您看到的结果是空的
kubectl logs -f nginx-pod-XXXXXXX

kubectl exec - 在pod中的容器环境内执行命令(和命令docker exec 类似)

# kubectl exec Pod名称 操作命令

# 在名称为nginx-pod-xxxxxx的Pod中运行bash
kubectl exec -it nginx-pod-xxxxxx /bin/bash

### 注意：新版1.21.0 提示这个命令会过期

4、kubectl run

也可以独立跑一个Pod

## kubectl run --help
kubectl run nginx --image=nginx

总结：

kubectl create 资源  #创建任意资源
kubectl create deploy #创建部署
kubectl run #只创建一个Pod
kubectl get 资源名(node/pod/deploy) -n xxx（指定名称空间，默认是default） #获取资源
kubectl describe  资源名(node/pod/deploy)  xxx #描述某个资源的详细信息
kubectl logs 资源名 ##查看日志
kubectl exec -it pod名 -- 命令  #进pod并执行命令
kubectl delete 资源名(node/pod/deploy) xxx  #删除资源

四、应用外部可见

了解 Kubernetes 中的 Service
了解标签(Label) 和标签选择器(Label Selector) 对象如何与 Service 关联
在 Kubernetes 集群外用 Service 暴露应用

1、Kubernetes Service 总览

Kubernetes Pod 是转瞬即逝的。
Pod 实际上拥有生命周期。当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。
ReplicaSet会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。
Kubernetes 的 Service 是一个抽象层，它定义了一组 Pod 的逻辑集，并为这些 Pod 支持外部流量暴露、负载平衡和服务发现。
- Service 使从属 Pod 之间的松耦合成为可能。和其他 Kubernetes 对象一样, Service 用 YAML 或者 JSON 来定义. Service 下的一组 Pod 通常由 LabelSelector (请参阅下面的说明为什么您可能想要一个 spec 中不包含selector的服务)来标记。
- 尽管每个 Pod 都有一个唯一的 IP 地址，但是如果没有 Service ，这些 IP 不会暴露在群集外部。Service 允许您的应用程序接收流量。Service 也可以用在 ServiceSpec 标记type的方式暴露
  - ClusterIP (默认) - 在集群的内部 IP 上公开 Service 。这种类型使得 Service 只能从集群内访问。
  - NodePort - 使用 NAT 在集群中每个选定 Node 的相同端口上公开 Service 。使用<NodeIP>:<NodePort> 从集群外部访问 Service。是 ClusterIP 的超集。
  - LoadBalancer - 在当前云中创建一个外部负载均衡器(如果支持的话)，并为 Service 分配一个固定的外部IP。是 NodePort 的超集。
  - ExternalName - 通过返回带有该名称的 CNAME 记录，使用任意名称(由 spec 中的externalName指定)公开 Service。不使用代理。这种类型需要kube-dns的v1.7或更高版本。

2、Service 和 Label

Service 通过一组 Pod 路由通信。Service 是一种抽象，它允许 Pod 死亡并在 Kubernetes 中复制，而不会影响应用程序。在依赖的 Pod (如应用程序中的前端和后端组件)之间进行发现和路由是由Kubernetes Service 处理的。

Service 匹配一组 Pod 是使用标签(Label)和选择器(Selector),它们是允许对 Kubernetes 中的对象进行逻辑操作的一种分组原语。标签(Label)是附加在对象上的键/值对，可以以多种方式使用:

指定用于开发，测试和生产的对象
嵌入版本标签
使用 Label 将对象进行分类

3、kubectl expose

 kubectl expose deployment tomcat6 --port=8912 --target-port=8080 --type=NodePort
 
 ## --port：集群内访问service的端口 8912
 ## --target-port： pod容器的端口 8080
 ## --nodePort： 每个机器开发的端口 30403
 
 
 ## 进行验证
 kubectl get svc 
 curl ip:port
 
 kubectl expose  #暴露，成一个负载均衡网络
 ## kubectl exec 进去pod修改，并测试负载均衡

五、伸缩应用程序-扩缩容

用 kubectl 扩缩应用程序
扩缩一个 Deployment

我们创建了一个Deployment ，然后通过服务提供访问 Pod 的方式。我们发布的 Deployment 只创建了一个 Pod 来运行我们的应用程序。当流量增加时，我们需要对应用程序进行伸缩操作以满足系统性能需求。

## 扩容的Pod会自动加入到他之前存在的Service（负载均衡网络）
kubectl scale --replicas=3  deployment tomcat6

#持续观测效果
watch kubectl get pods -o wide

六、执行滚动升级

使用 kubectl 执行滚动更新

滚动更新允许通过使用新的实例逐步更新 Pod 实例从而实现 Deployments 更新，停机时间为零。

与应用程序扩展类似，如果暴露了 Deployment，服务（Service）将在更新期间仅对可用的 pod 进行负载均衡。可用 Pod 是应用程序用户可用的实例。

滚动更新允许以下操作：

将应用程序从一个环境提升到另一个环境（通过容器镜像更新）
回滚到以前的版本
持续集成和持续交付应用程序，无需停机

#应用升级: tomcat:alpine、tomcat:jre8-alpine
# kubectl set image deployment/my-nginx2  nginx=nginx:1.9.1

##联合jenkins 形成持续集成，灰度发布功能
kubectl set image deployment.apps/tomcat6 tomcat=tomcat:jre8-alpine #可以携带--record参数，记录变更


##回滚升级
### 查看历史记录
kubectl rollout history deployment.apps/tomcat6
kubectl rollout history deploy tomcat6

### 回滚到指定版本
kubectl rollout undo deployment.apps/tomcat6 --to-revision=1
kubectl rollout undo deploy tomcat6 --to-revision=1

七、使用配置文件方式

1、部署一个应用

apiVersion: apps/v1	#与k8s集群版本有关，使用 kubectl api-versions 即可查看当前集群支持的版本
kind: Deployment	#该配置的类型，我们使用的是 Deployment
metadata:	        #译名为元数据，即 Deployment 的一些基本属性和信息
  name: nginx-deployment	#Deployment 的名称
  labels:	    #标签，可以灵活定位一个或多个资源，其中key和value均可自定义，可以定义多组，目前不需要理解
    app: nginx	#为该Deployment设置key为app，value为nginx的标签
spec:	        #这是关于该Deployment的描述，可以理解为你期待该Deployment在k8s中如何使用
  replicas: 1	#使用该Deployment创建一个应用程序实例
  selector:	    #标签选择器，与上面的标签共同作用，目前不需要理解
    matchLabels: #选择包含标签app:nginx的资源
      app: nginx
  template:	    #这是选择或创建的Pod的模板
    metadata:	#Pod的元数据
      labels:	#Pod的标签，上面的selector即选择包含标签app:nginx的Pod
        app: nginx
    spec:	    #期望Pod实现的功能（即在pod中部署）
      containers:	#生成container，与docker中的container是同一种
      - name: nginx	#container的名称
        image: nginx:1.7.9	#使用镜像nginx:1.7.9创建container，该container默认80端口可访问

kubectl apply -f xxx.yaml

2、暴露应用

apiVersion: v1
kind: Service
metadata:
  name: nginx-service	#Service 的名称
  labels:     	#Service 自己的标签
    app: nginx	#为该 Service 设置 key 为 app，value 为 nginx 的标签
spec:	    #这是关于该 Service 的定义，描述了 Service 如何选择 Pod，如何被访问
  selector:	    #标签选择器
    app: nginx	#选择包含标签 app:nginx 的 Pod
  ports:
  - name: nginx-port	#端口的名字
    protocol: TCP	    #协议类型 TCP/UDP
    port: 80	        #集群内的其他容器组可通过 80 端口访问 Service
    nodePort: 32600   #通过任意节点的 32600 端口访问 Service
    targetPort: 80	#将请求转发到匹配 Pod 的 80 端口
  type: NodePort	#Serive的类型，ClusterIP/NodePort/LoaderBalancer