Deployment和service-04

前面我们已经了解到，Kubernetes 通过各种 Controller 来管理 Pod 的生命周期。为了满足不同业务场景，Kubernetes 开发了 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等多种 Controller。我们首先学习最常用的 Deployment。

pod
pod是k8s的最小工作单元。每个pod包含一个或者多个容器。pod中的容器会作为一个整体被master调度到一个node上运行。
5.controller
k8s通常不会直接创建pod,而是通过controller来管理pod的。controller中定义了pod的部署特性，比如有几个剧本，在什么样的node上运行等。为了满足不同的业务场景，k8s提供了多种controller，包括deployment、replicaset、daemonset、statefulset、job等。
deployment
是最常用的controller。deployment可以管理pod的多个副本，并确保pod按照期望的状态运行。
replicaset
实现了pod的多副本管理。使用deployment时会自动创建replicaset，也就是说deployment是通过replicaset来管理pod的多个副本的，我们通常不需要直接使用replicaset。
daemonset
用于每个node最多只运行一个pod副本的场景。正如其名称所示的，daemonset通常用于运行daemon。
statefuleset
能够保证pod的每个副本在整个生命周期中名称是不变的，而其他controller不提供这个功能。当某个pod发生故障需要删除并重新启动时，pod的名称会发生变化，同时statefulset会保证副本按照固定的顺序启动、更新或者删除。、
job
用于运行结束就删除的应用，而其他controller中的pod通常是长期持续运行的。
service
deployment可以部署多个副本，每个pod 都有自己的IP，外界如何访问这些副本？
答案是service
k8s的 service定义了外界访问一组特定pod的方式。service有自己的IP和端口，service为pod提供了负载均衡。
k8s运行容器pod与访问容器这两项任务分别由controller和service执行。
namespace
可以将一个物理的cluster逻辑上划分成多个虚拟cluster，每个cluster就是一个namespace。不同的namespace里的资源是完全隔离的。

运行一个 Deployment

kubectl run nginx-deployment --image=nginx --replicas=2
上面的命令将部署包含两个副本的 Deployment nginx-deployment，容器的 image 为nginx:laster

kubectl get deployment 命令可以查看 nginx-deployment 的状态，输出显示两个副本正常运行。
接下来我们用 kubectl describe deployment 了解更详细的信息。

大部分内容都是自解释的，我们重点看最下面部分。这里告诉我们创建了一个 ReplicaSet nginx-deployment-1260880958，Events 是 Deployment 的日志，记录了 ReplicaSet 的启动过程。
通过上面的分析，也验证了 Deployment 通过 ReplicaSet 来管理 Pod 的事实。接着我们将注意力切换到 nginx-deployment-69f748fb86，
执行 kubectl describe replicaset：

Controlled By 指明此 ReplicaSet 是由 Deployment nginx-deployment 创建。Events 记录了两个副本 Pod 的创建。接着我们来看 Pod，
执行 kubectl get pod：

两个副本 Pod 都处于 Running 状态，用 kubectl describe pod 查看更详细的信息：

Controlled By 指明此 Pod 是由 ReplicaSet nginx-deployment-1260880958 创建。Events 记录了 Pod 的启动过程。如果操作失败（比如 image 不存在），也能在这里查看到原因。
总结一下这个过程：
用户通过 kubectl 创建 Deployment。
Deployment 创建 ReplicaSet。
ReplicaSet 创建 Pod。

从上图也可以看出，对象的命名方式是：子对象的名字 = 父对象名字 + 随机字符串或数字。
本节我们是通过 kubectl run 创建的 Deployment，下一节学习另一种更常用的方法。

通过 Service 访问 Pod

我们不应该期望 Kubernetes Pod 是健壮的，而是要假设 Pod 中的容器很可能因为各种原因发生故障而死掉。Deployment 等 controller 会通过动态创建和销毁 Pod 来保证应用整体的健壮性。换句话说，Pod 是脆弱的，但应用是健壮的。
每个 Pod 都有自己的 IP 地址。当 controller 用新 Pod 替代发生故障的 Pod 时，新 Pod 会分配到新的 IP 地址。这样就产生了一个问题：
如果一组 Pod 对外提供服务（比如 HTTP），它们的 IP 很有可能发生变化，那么客户端如何找到并访问这个服务呢？
Kubernetes 给出的解决方案是 Service。

创建 Service

Kubernetes Service 从逻辑上代表了一组 Pod，具体是哪些 Pod 则是由 label 来挑选。Service 有自己 IP，而且这个 IP 是不变的。客户端只需要访问 Service 的 IP，Kubernetes 则负责建立和维护 Service 与 Pod 的映射关系。无论后端 Pod 如何变化，对客户端不会有任何影响，因为 Service 没有变。
来看个例子，创建下面的这个 Deployment：

[root@master ~]# cat httpd.yml 
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: httpd
spec:
  replicas: 3
  template:
    metadata:
      labels:
        run: httpd
    spec:
      containers:
      - name: httpd
        image: httpd
        ports:
        - containerPort: 80

我们启动了三个 Pod，运行 httpd 镜像，label 是 run: httpd，Service 将会用这个 label 来挑选 Pod。

Pod 分配了各自的 IP，这些 IP 只能被 Kubernetes Cluster 中的容器和节点访问。
接下来创建 Service，其配置文件如下：

[root@master ~]# cat  http-service.yml 
apiVersion: v1
kind: Service
metadata:
  name: httpd-svc
spec:
  selector:
    run: httpd
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 80

① v1 是 Service 的 apiVersion。
② 指明当前资源的类型为 Service。
③ Service 的名字为 httpd-svc。
④ selector 指明挑选那些 label 为 run: httpd 的 Pod 作为 Service 的后端。
⑤ 将 Service 的 8080 端口映射到 Pod 的 80 端口，使用 TCP 协议。

执行 kubectl apply 创建 Service httpd-svc。

httpd-svc 分配到一个 CLUSTER-IP 10.111.219.214。可以通过该 IP 访问后端的 httpd Pod。

根据前面的端口映射，这里要使用 8080 端口。另外，除了我们创建的 httpd-svc，还有一个 Service kubernetes，Cluster 内部通过这个 Service 访问 kubernetes API Server。

通过 kubectl describe 可以查看 httpd-svc 与 Pod 的对应关系。

Endpoints 罗列了三个 Pod 的 IP 和端口。我们知道 Pod 的 IP 是在容器中配置的，那么 Service 的 Cluster IP 又是配置在哪里的呢？CLUSTER-IP 又是如何映射到 Pod IP 的呢？
答案是 iptables

Service Cluster IP 的底层实现

Service deCluster IP 是一个虚拟 IP，是由 Kubernetes 节点上的 iptables 规则管理的。
可以通过 iptables-save 命令打印出当前节点的 iptables 规则，因为输出较多，这里只截取与 httpd-svc Cluster IP 10.111.219.214 相关的信息：

这两条规则的含义是：

如果 Cluster 内的 Pod（源地址来自 10.244.0.0/16）要访问 httpd-svc，则允许。
2 其他源地址访问 httpd-svc，跳转到规则 KUBE-SVC-RL3JAE4GN7VOGDGP。

KUBE-SVC-RL3JAE4GN7VOGDGP 规则如下：

1/3 的概率跳转到规则 KUBE-SEP-5TOGU7RW6ODB2NEU
1/3 的概率（剩下 2/3 的一半）跳转到规则 KUBE-SEP-WCXDXF365ATAGI2F
1/3 的概率跳转到规则KUBE-SEP-IRMT6RY5EEEBXDAY

上面三个跳转的规则如下：

即将请求分别转发到后端的三个 Pod。通过上面的分析，我们得到如下结论：
iptables 将访问 Service 的流量转发到后端 Pod，而且使用类似轮询的负载均衡策略。
另外需要补充一点：Cluster 的每一个节点都配置了相同的 iptables 规则，这样就确保了整个 Cluster 都能够通过 Service 的 Cluster IP 访问 Service。
除了直接通过 Cluster IP 访问到 Service，DNS 是更加便捷的方式，下一节我们讨论。

外网如何访问 Service

除了 Cluster 内部可以访问 Service，很多情况我们也希望应用的 Service 能够暴露给 Cluster 外部。Kubernetes 提供了多种类型的 Service，默认是 ClusterIP。

ClusterIP
Service 通过 Cluster 内部的 IP 对外提供服务，只有 Cluster 内的节点和 Pod 可访问，这是默认的 Service 类型，前面实验中的 Service 都是 ClusterIP。
NodePort
Service 通过 Cluster 节点的静态端口对外提供服务。Cluster 外部可以通过 <NodeIP>:<NodePort> 访问 Service。
LoadBalancer
Service 利用 cloud provider（云厂商）特有的 load balancer 对外提供服务，cloud provider 负责将 load balancer 的流量导向 Service。目前支持的 cloud provider 有 GCP、AWS、Azur 等。
下面我们来实践 NodePort，Service httpd-svc 的配置文件修改如下：

添加 type: NodePort，重新创建 httpd-svc。

Kubernetes 依然会为 httpd-svc 分配一个 ClusterIP，不同的是：
EXTERNAL-IP 为 nodes，表示可通过 Cluster 每个节点自身的 IP 访问 Service。
PORT(S) 为 8080:32312。8080 是 ClusterIP 监听的端口，32312 则是节点上监听的端口。Kubernetes 会从 30000-32767 中分配一个可用的端口，每个节点都会监听此端口并将请求转发给 Service。

下面测试 NodePort 是否正常工作。

通过三个节点 IP + 32312 端口都能够访问 httpd-svc。

接下来我们深入探讨一个问题：Kubernetes 是如何将 <NodeIP>:<NodePort> 映射到 Pod 的呢？
与 ClusterIP 一样，也是借助了 iptables。与 ClusterIP 相比，每个节点的 iptables 中都增加了下面两条规则：

规则的含义是：访问当前节点 32312 端口的请求会应用规则 KUBE-SVC-RL3JAE4GN7VOGDGP，内容为

其作用就是负载均衡到每一个 Pod。
NodePort 默认是的随机选择，不过我们可以用 nodePort 指定某个特定端口

现在配置文件中就有三个 Port 了：
nodePort 是节点上监听的端口。
port 是 ClusterIP 上监听的端口。
targetPort 是 Pod 监听的端口。
最终，Node 和 ClusterIP 在各自端口上接收到的请求都会通过 iptables 转发到 Pod 的 targetPort。
应用新的 nodePort 并验证：

Rolling Update

滚动更新是一次只更新一小部分副本，成功后，再更新更多的副本，最终完成所有副本的更新。滚动更新的最大的好处是零停机，整个更新过程始终有副本在运行，从而保证了业务的连续性。
实践
下面我们部署三副本应用，初始镜像为 httpd:2.2.31，然后将其更新到 httpd:2.2.32。
httpd:2.2.31 的配置文件如下：

通过 kubectl apply 部署。

部署过程如下：

创建 Deployment httpd
创建 ReplicaSet httpd-5ddb558f47
创建三个 Pod
当前镜像为 httpd:2.2.31

将配置文件中 httpd:2.2.31 替换为 httpd:2.2.32，再次执行 kubectl apply。

我们发现了如下变化：

Deployment httpd 的镜像更新为 httpd:2.2.32
新创建了 ReplicaSet httpd-8bdffc6d8，镜像为 httpd:2.2.32，并且管理了三个新的 Pod。
之前的 ReplicaSet httpd-5ddb558f47里面k已经没有任何 Pod。

结论是：ReplicaSet httpd-5ddb558f47的三个 httpd:2.2.31 Pod 已经被 ReplicaSet httpd-8bdffc6d8 的三个 httpd:2.2.32 Pod 替换了。

每次只更新替换一个 Pod：
ReplicaSet httpd-8bdffc6d8 增加一个 Pod，总数为 1。
ReplicaSet httpd-5ddb558f47减少一个 Pod，总数为 2。
ReplicaSet httpd-8bdffc6d8 增加一个 Pod，总数为 2。
ReplicaSet httpd-5ddb558f47减少一个 Pod，总数为 1。
ReplicaSet httpd-8bdffc6d8 增加一个 Pod，总数为 3。
ReplicaSet httpd-5ddb558f47减少一个 Pod，总数为 0。

每次替换的 Pod 数量是可以定制的。Kubernetes 提供了两个参数 maxSurge 和 maxUnavailable 来精细控制 Pod 的替换数量，我们将在后面结合 Health Check 特性一起讨论。

回滚

kubectl apply 每次更新应用时 Kubernetes 都会记录下当前的配置，保存为一个 revision（版次），这样就可以回滚到某个特定 revision。
默认配置下，Kubernetes 只会保留最近的几个 revision，可以在 Deployment 配置文件中通过 revisionHistoryLimit 属性增加 revision 数量。
下面实践回滚功能。应用有如下三个配置文件 httpd.v1.yml，httpd.v2.yml 和 httpd.v3.yml，分别对应不同的 httpd 镜像 2.4.16，2.4.17 和 2.4.18：

[root@master ~]# cat  httpd.v1.yml 
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: httpd
spec:
  revisionHistoryLimit: 10
  replicas: 3
  template:
    metadata:
      labels:
        run: httpd
    spec:
      containers:
      - name: httpd
        image: httpd:2.4.16
        ports:
        - containerPort: 80
[root@master ~]# 
[root@master ~]# cat  httpd.v2.yml 
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: httpd
spec:
  revisionHistoryLimit: 10
  replicas: 3
  template:
    metadata:
      labels:
        run: httpd
    spec:
      containers:
      - name: httpd
        image: httpd:2.4.17
        ports:
        - containerPort: 80
[root@master ~]# 
[root@master ~]# cat  httpd.v3.yml 
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: httpd
spec:
  revisionHistoryLimit: 10
  replicas: 3
  template:
    metadata:
      labels:
        run: httpd
    spec:
      containers:
      - name: httpd
        image: httpd:2.4.18
        ports:
        - containerPort: 80
[root@master ~]#

通过 kubectl apply 部署并更新应用：

–record 的作用是将当前命令记录到 revision 记录中，这样我们就可以知道每个 revison 对应的是哪个配置文件。通过 kubectl rollout history deployment httpd 查看 revison 历史记录。

CHANGE-CAUSE 就是 --record 的结果。如果要回滚到某个版本，比如 revision 1，可以执行命令 kubectl rollout undo deployment httpd --to-revision=1：

此时，revison 历史记录也会发生相应变化。

revison 1 变成了 revison 4。不过我们可以通过 CHANGE-CAUSE 知道每个 revison 的具体含义。所以一定要在执行 kubectl apply 时加上 --record 参数。

Deployment和service-04

运行一个 Deployment

通过 Service 访问 Pod

创建 Service

Service Cluster IP 的底层实现

外网如何访问 Service

Rolling Update

回滚

24-5-18 X

kubeadm部署安裝K8S集羣及核心概念-02

k8s創建pod資源對象-03

KVM遷移及優化-06

Deployment和service-04

kubernetes介紹-01

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結