k8s笔记4--k8s基础概念

1 k8s 概述

Kubernetes 是谷歌开源的容器集群管理系统，是 Google 多年大规模容器管理技术 Borg 的开源版本。其发展非常迅速，已经成为容器编排领域的领导者。

Kubernetes 是一个平台。它提供了很多的功能，可以简化应用程序的工作流，加快开发速度。通常，一个成功的应用编排系统需要有较强的自动化能力，这也是为什么 Kubernetes 被设计作为构建组件和工具的生态系统平台，以便更轻松地部署、扩展和管理应用程序。
用户可以使用 Label 以自己的方式组织管理资源，还可以使用 Annotation 来自定义资源的描述信息，比如为管理工具提供状态检查等。
此外，Kubernetes 控制器也是构建在跟开发人员和用户使用的相同的 API 之上。用户还可以编写自己的控制器和调度器，也可以通过各种插件机制扩展系统的功能。这种设计使得可以方便地在 Kubernetes 之上构建各种应用系统。

2 功能特性

1. 功能(kubenetes指南)
   • 基于容器的应用部署、维护和滚动升级
   • 负载均衡和服务发现
   • 跨机器和跨地区的集群调度
   • 自动伸缩
   • 无状态服务和有状态服务
   • 广泛的 Volume 支持
   • 插件机制保证扩展性
2. 特性(阿良教程)
   • 自我修护
   • 弹性伸缩
   • 自动部署和回滚
   • 服务发现和负载均衡
   • 机密和配置管理
   • 存储编排
   • 批处理

3 核心组件

Kubernetes 主要由以下几个核心组件组成:

1. etcd 保存了整个集群的状态；
2. API Server 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制；
3. Controller Manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
4. Scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；
5. Kubelet 负责维护容器的生命周期，同时也负责 Volume（CVI）和网络（CNI）的管理；
6. Container Runtime 负责镜像管理以及 Pod 和容器的真正运行（CRI）；
7. Kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡；

4 资源对象

Kubernetes 包含如下资源对象：

名称	主要功能	其它
Autoscaling (HPA)	可以根据 CPU 使用率或应用自定义 metrics 自动扩展 Pod 数量（支持 replication controller、deployment 和 replica set ）
ConfigMap	ConfigMap 用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。ConfigMap 跟 Secret 很类似，但它可以更方便地处理不包含敏感信息的字符串。
CronJob	CronJob 即定时任务，就类似于 Linux 系统的 crontab，在指定的时间周期运行指定的任务。
CustomResourceDefinition	v1.7 新增的无需改变代码就可以扩展 Kubernetes API 的机制，用来管理自定义对象; v1.8 中已经弃用。
DaemonSet	DaemonSet 保证在每个 Node 上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。
Deployment	Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法，用来替代以前的 ReplicationController 来方便的管理应用。
Ingress	Ingress 可以给 service 提供集群外部访问的 URL、负载均衡、SSL 终止、HTTP 路由等
Job	Job 负责批量处理短暂的一次性任务 (short lived one-off tasks)，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束。
LocalVolume	本地数据卷（Local Volume）代表一个本地存储设备，比如磁盘、分区或者目录等。
Namespace	Namespace 是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组或用户组。常见的 pod, service, replication controller 和 deployment 等都是属于某一个 namespace 的（默认是 default），而 node, persistent volume，namespace 等资源则不属于任何 namespace。
NetworkPolicy	Network Policy 提供了基于策略的网络控制，用于隔离应用并减少攻击面。它使用标签选择器模拟传统的分段网络，并通过策略控制它们之间的流量以及来自外部的流量。
Node	Node 是 Pod 真正运行的主机，可以是物理机，也可以是虚拟机。为了管理 Pod，每个 Node 节点上至少要运行 container runtime（比如 docker 或者 rkt）、kubelet 和 kube-proxy 服务。
PersistentVolume	PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 提供了方便的持久化卷：PV 提供网络存储资源，而 PVC 请求存储资源。这样，设置持久化的工作流包括配置底层文件系统或者云数据卷、创建持久性数据卷、最后创建 PVC 来将 Pod 跟数据卷关联起来。PV 和 PVC 可以将 pod 和数据卷解耦，pod 不需要知道确切的文件系统或者支持它的持久化引擎。
Pod	Pod 是一组紧密关联的容器集合，它们共享 IPC、Network 和 PID namespace，是 Kubernetes 调度的基本单位。Pod 的设计理念是支持多个容器在一个 Pod 中共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。
PodPreset	PodPreset 用来给指定标签的 Pod 注入额外的信息，如环境变量、存储卷等。这样，Pod 模板就不需要为每个 Pod 都显式设置重复的信息。
ReplicaSet	ReplicationController（也简称为 rc）用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的 Pod 来替代；而异常多出来的容器也会自动回收。ReplicationController 的典型应用场景包括确保健康 Pod 的数量、弹性伸缩、滚动升级以及应用多版本发布跟踪等。 在新版本的 Kubernetes 中建议使用 ReplicaSet（也简称为 rs）来取代 ReplicationController。ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字不一样，并且 ReplicaSet 支持集合式的 selector（ReplicationController 仅支持等式）。
Resource Quota	资源配额（Resource Quotas）是用来限制用户资源用量的一种机制。它的工作原理为: 资源配额应用在 Namespace 上，并且每个 Namespace 最多只能有一个 ResourceQuota 对象; 开启计算资源配额后，创建容器时必须配置计算资源请求或限制（也可以用 LimitRange 设置默认值）;用户超额后禁止创建新的资源
Secret	Secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec 中。Secret 可以以 Volume 或者环境变量的方式使用。
SecurityContext	Security Context 的目的是限制不可信容器的行为，保护系统和其他容器不受其影响。
Service	Service 是对一组提供相同功能的 Pods 的抽象，并为它们提供一个统一的入口。借助 Service，应用可以方便的实现服务发现与负载均衡，并实现应用的零宕机升级。Service 通过标签来选取服务后端，一般配合 Replication Controller 或者 Deployment 来保证后端容器的正常运行。这些匹配标签的 Pod IP 和端口列表组成 endpoints，由 kube-proxy 负责将服务 IP 负载均衡到这些 endpoints 上。
ServiceAccount	Service account 是为了方便 Pod 里面的进程调用 Kubernetes API 或其他外部服务而设计的。
StatefulSet	StatefulSet 是为了解决有状态服务的问题（对应 Deployments 和 ReplicaSets 是为无状态服务而设计），其应用场景包括:稳定的持久化存储;稳定的网络标志;有序部署，有序扩展;有序收缩，有序删除。
Volume	默认情况下容器的数据都是非持久化的，在容器消亡以后数据也跟着丢失，所以 Docker 提供了 Volume 机制以便将数据持久化存储。类似的，Kubernetes 提供了更强大的 Volume 机制和丰富的插件，解决了容器数据持久化和容器间共享数据的问题。 与 Docker 不同，Kubernetes Volume 的生命周期与 Pod 绑定：容器挂掉后 Kubelet 再次重启容器时，Volume 的数据依然还在；而 Pod 删除时，Volume 才会清理。数据是否丢失取决于具体的 Volume 类型，比如 emptyDir 的数据会丢失，而 PV 的数据则不会丢。

4.1 pod 概述

• 存在的意义
  pod 为亲密性应用而存在，应用场景：
  1）两个应用之间发生文件交互；
  2）两个应用需要通过127.0.0.1 或 socket 通信；
  3）两个应用需要发生频繁的调用；

• 实现机制
  Pod 天生地为其成员容器提供了两种共享资源：网络和 存储。

  k8s 中每创建一个pod，都会创建基于 registry.aliyuncs.com/google_containers/pause:3.2 镜像的容器(infra容器)，该容器创建一个网络命名空间, pod 内的其它容器都会加入该命名空间，从而实现了 pod内其它容器共享网络资源；

  此处创建一个 deployment 包含nginx 和flask-app, 进入容器内部发现2者的ip a 信息是一样的（nginx 默认没有ip命令，需要 apt-get install iproute2 安装); 进一步可以通过netsta 查看，发现在如何容器内部都可以看到2个容器的端口信息; 其原因是它们具有相同的网络协议栈，共享网络资源。
  deployment 包括2个容器：

  apiVersion: apps/v1
  kind: Deployment
  metadata:
   labels:
     app: my-web
   name: my-web
  spec:
   replicas: 1
   selector:
     matchLabels:
       app: my-web
   template:
     metadata:
       labels:
         app: my-web
     spec:
       containers:
       - image: nginx
         name: nginx
       - image: ubuntu_flask:v1.0
         name: flask-app
         imagePullPolicy: IfNotPresent
  

  同样，一个pod内的容器可以通过volume的方式共享数据，以下定义了一pod，write向/data/hello 中写数据， read 从/data/hello中读数据；
  通过 kubectl apply -f my-os.yaml 起pod后，就可以查看容器中的数据了；

  apiVersion: v1
  kind: Pod
  metadata:
    name: my-os
    namespace: test-online
  spec:
    containers:
    - image: ubuntu:20.04
      name: write
      command: ["bash", "-c", "for i in {1..100};do echo $i >>/data/hello;sleep 1;done"]
      volumeMounts:
      - mountPath: /data
        name: test-data
    - image: ubuntu:20.04
      name: read
      command: ["bash", "-c", "tail -f /data/hello"]
      volumeMounts:
      - mountPath: /data
        name: test-data
    volumes:
    - name: test-data
      emptyDir: {}
  

• pod template常见字段
  pod 模板中常用字段段包括：变量(env)，拉取镜像(image)，资源限制(resource)，监控检查(readinessProbe, livenessProbe)；

4.2 deployment 概述

功能及应用场景

1. pod 与controlers关系

   • controller： 在集群层面管理和运行容器的对象, 控制器也称为workload
   • 通过label-selector相关联，即通过标签来关联一组pod
   • pod 通过控制器实现应用的运维，如伸缩、滚动升级等

2. deployment 功能场景

   • 部署无状态应用
   • 管理pod和ReplicaSet
   • 具有线上部署、副本设定、滚动升级、回滚等功能
   • 提供声明式更新，例如只更新一个新的Image
     应用场景：web服务，微服务

3. 使用deploment部署java应用
   控制器定义：apiVersion，kind，metadata，spec
   被控制对象：template{metadata,spec}
   kubectl create deployment --help
   kubectl create deployment web --image=nginx --dry-run -o yaml(或者web.yaml)
   kubectl create deployment test-nginx --image=nginx --dry-run -o yaml > test-nginx.yaml

   然后更改对应的参数和image即可；
   kubectl apply -f test-nginx.yaml
   使用service 和 ingress 暴露出应用；
   kubectl expose deployment test-nginx --port=80 --target-port=80 --type=NodePort -o yaml --dry-run >svc-test-nginx.yaml (第二个端口80为pod中服务端口)
   kubectl apply -f svc-test-nginx.yaml
   kubectl get service

   查看创建的pod：

   # kubectl get pods,svc
   NAME                              READY   STATUS    RESTARTS   AGE
   pod/nginx-554b9c67f9-jbclt        1/1     Running   3          4d19h
   pod/test-nginx-76b4548894-w4qft   1/1     Running   0          5m58s
   
   NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
   service/kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP        4d20h
   service/nginx        NodePort    10.96.136.149    <none>        80:32063/TCP   4d19h
   service/test-nginx   NodePort    10.104.136.169   <none>        80:31400/TCP   29s
   此时使用 http://192.168.2.134:31400/即可访问test-nginx服务了
   

4. 应用升级、回滚、弹性伸缩
   升级：
   kubectl set image xxx
   回滚：
   kubectl rollout history|undo xxx
   删除：
   kubectl delete deployment
   弹性伸缩：
   kubectl scale deployment web --replicas=5

4.3 service

1. service 存在的意义

   • 防止pod失联(服务发现)
     service 可以动态发现一组应用的pod以及其ip，
     service 具备负载均衡，为一组pod进行负载均衡(TCP/UDP 4层)，
     service 关联一种应用，例如service A 关联前端，service B 关联后段
   • 与pod的关联
     通过label进行关联，因此需要保证label的唯一性；

2. service 类型

   • ClusterIP
     在集群内部使用，
   • NodePort
     在每个node上创建端口，默认30000起
   • Loadbalancer
     主要用于公有云场景，其完成了自动添加ip:端口到lb中
   • ExternalName
     将服务通过 DNS CNAME 记录方式转发到指定的域名（通过 spec.externlName 设定）

   service NodePort 对外暴露应用，其在每个node上启一个端口，通过nodeip:port 即可访问；
   LB 多用于在共有云上部署k8s，通过LB实现负载均衡；

4.4 Ingress 介绍

1. NodePort 存在的问题
   • NodePort 需要监听端口，存在端口冲突；
   • NodePort 是四层负载均衡，无法通过uri转发，此时需要使用层负载均衡实现转发；
   • NodePort 无法实现通过一个统一入口进行所有转发功能 kubenete do not show default ns
2. Ingress 对外暴露应用
   • 通过service 关联pod
   • 基于域名访问
   • 通过ingerss controller实现pod的负载均衡，支持tcp|udp 4层 和http 7层
     ingress 通过upstream 来代理一系列的pod；
3. Ingress 操作实战
   ingress.yaml 需要指定域名|host，service 和 nodePort
4. Ingress Nginx 工作原理
   通过ingress 的nginx 转发到具体的pod中。

5 说明

kubenetes 指南
1 天入门Kubernetes/K8S
k8s 中文官方文档
k8s 英文官方文档