kubernetes 的马洛斯需求

kubernetes 架构图

kubernetes 主要基本概念和术语

master
- 1. Kubernets API server,提供
- 1. Kubernets Controlle Manager (kube-controller-manager),kubernets 里面所有资源对象的自动化控制中心，可以理解为资源对象的大总管。
- 1. Kubernets Scheduler (kube-scheduler),负责资源调度（pod调度）的进程，相当去公交公司的‘调度室’
node

每个Node 节点上都运行着以下一组关键进程
- 1. kubelet：负责pod对应的容器创建、启停等任务，同时与master 节点密切协作，实现集群管理的基本功能。
- 2. kube-proxy:实现kubernetes Service 的通信与负载均衡机制的重要组件。
- 3. Docker Engine: Docker 引擎，负责本机的容器创建和管理工作。

pod：

Pod是kubernetes中可以创建的最小部署单元
V1 core版本的Pod的配置模板见Pod Template
Example：创建一个tomcat实例

apiVersion: vl
kind: Pod
metadata:
name: myweb
labels:
name: myweb
spec:
containers:
- name: myweb
  image: kubeguide/tomcat-app:vl
  ports:
- containerPort: 8080
  env:
- name: MYSQL_SERVICE_HOST
  value: 'mysql'
- name: MYSQL_SERVICE_PORT
  value: '3306'

label（标签）
- 1. 一个label是一个key=value的简直对，其中key与value由用户自己指定。Label可以附加到各种资源对象上，列入Node、pod、Server、RC 等。
- 1. Label 示例如下:
```
版本标签：release:stable,release:canary
环境标签：environment:dev,environment:qa,environment:production
架构标签: tier:frontend,tier:backend,tier:cache
分区标签：partition:customerA,partition:customerB
质量管控标签：track:daily,track:weekly
```
- 1. Label selector
    Label不是唯一的，很多object可能有相同的label
    通过label selector，客户端／用户可以指定一个object集合，通过label selector对object的集合进行操作。
  - Label selector有两种类型：
    - equality-based ：可以使用=、==、!=操作符，可以使用逗号分隔多个表达式
    - et-based ：可以使用in、notin、!操作符，另外还可以没有操作符，直接写出某个label的key，表示过滤有某个key的object而不管该key的value是何值，!表示没有该label的object
    - 示例
```
$ kubectl get pods -l 'environment=production,tier=frontend'
$ kubectl get pods -l 'environment in (production),tier in (frontend)'
$ kubectl get pods -l 'environment in (production, qa)'
$ kubectl get pods -l 'environment,environment notin (frontend)'
```
    - Label Selector 的作用范围1
    - Label Selector 的作用范围2

Replication Contoller

简述：

定义了一个期望的场景，即声明某种Pod的副本数量在任意时刻都符合某个预期值，所以RC的定义包含如下几个场景：

1. Pod 期待的副本数
1. 用于筛选Pod的Label Selector
1. 当pod的副本数量小于预期的时候，用于创建新的Pod的pod模板（Template）
1. 一个完整的RC示例：

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: frontend
  # these labels can be applied automatically
  # from the labels in the pod template if not set
  # labels:
    # app: guestbook
    # tier: frontend
spec:
  # this replicas value is default
  # modify it according to your case
  replicas: 3
  # selector can be applied automatically
  # from the labels in the pod template if not set,
  # but we are specifying the selector here to
  # demonstrate its usage.
  selector:
    matchLabels:
      tier: frontend
    matchExpressions:
      - {key: tier, operator: In, values: [frontend]}
  template:
    metadata:
      labels:
        app: guestbook
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        env:
        - name: GET_HOSTS_FROM
          value: dns
          # If your cluster config does not include a dns service, then to
          # instead access environment variables to find service host
          # info, comment out the 'value: dns' line above, and uncomment the
          # line below.
          # value: env
        ports:
        - containerPort: 80

Deployment
- 简述
Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController 来方便的管理应用。
- 典型的应用场景包括：
  - 使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态，看它是成功还是失败。
  - 然后，通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSet，Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。
  - 如果当前状态不稳定，回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision。
  - 扩容Deployment以满足更高的负载。
  - 暂停Deployment来应用PodTemplateSpec的多个修复，然后恢复上线。
  - 根据Deployment 的状态判断上线是否hang住了。
  - 清除旧的不必要的 ReplicaSet。
- 一个简单的nginx 应用可以定义为：
```
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
    name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80
```
Horizontal Pod Autoscaler
- 简述：
  应用的资源使用率通常都有高峰和低谷的时候，如何削峰填谷，提高集群的整体资源利用率，让service中的Pod个数自动调整呢？这就有赖于Horizontal Pod Autoscaling了，顾名思义，使Pod水平自动缩放。这个Object（跟Pod、Deployment一样都是API resource）也是最能体现kubernetes之于传统运维价值的地方，不再需要手动扩容了，终于实现自动化了，还可以自定义指标，没准未来还可以通过人工智能自动进化呢！
- Metrics支持
在不同版本的API中，HPA autoscale时可以根据以下指标来判断：
- autoscaling/v1
  - CPU
- autoscaling/v2alpha1
  - 内存
  - 自定义
    - kubernetes1.6起支持自定义metrics，但是必须在kube-controller-manager中配置如下两项
      - --horizontal-pod-autoscaler-use-rest-clients=true
      - --api-server指向kube-aggregator，也可以使用heapster来实现，通过在启动heapster的时候指定--api-server=true。查看kubernetes metrics
  - 多种metrics组合
    - HPA会根据每个metric的值计算出scale的值，并将最大的那个指作为扩容的最终结果
- 一个简单的HPA示例：
```
apiVersion: autoscaling/vl
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  maxReplicas:	5
  minReplicas:	2
scaleTargetRef:
  kind: Deployment
  name: php-apache
targetCPUUtilizationPercentage:	90
```
Service
- 简述：
  - Kubernetes Service 定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector（查看下面了解，为什么可能需要没有 selector 的 Service）实现的。
- Pod、 RC 与Service的关系
- Endpoint: Pod IP + Container Port
- 一个service 示例
```
  kind: Service
  apiVersion: v1
  metadata:
    name: my-service
  spec:
    selector:
      app: MyApp
    ports:
      - protocol: TCP
        port: 80
        targetPort: 9376
```
- kubernetes 的服务发现机制
Kubernetes 支持2种基本的服务发现模式 —— 环境变量和 DNS。
1. - 环境变量
当 Pod 运行在 Node 上，kubelet 会为每个活跃的 Service 添加一组环境变量。它同时支持 Docker links 兼容变量（查看 makeLinkVariables）、简单的 {SVCNAME}_SERVICE_HOST 和 {SVCNAME}_SERVICE_PORT 变量，这里 Service 的名称需大写，横线被转换成下划线。

举个例子，一个名称为 "redis-master" 的 Service 暴露了 TCP 端口 6379，同时给它分配了 Cluster IP 地址 10.0.0.11，这个 Service 生成了如下环境变量：
```
REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_PORT=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_MASTER_PORT_6379_TCP_PORT=6379
REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11
```
1. - DNS
kubernets 通过Add-On增值包的方式引入了DNS 系统，把服务名称作为DNS域名，这样一来，程序就可以直接使用服务名来建立通信连接。目前kubernetes上的大部分应用都已经采用了DNS这一种发现机制，在后面的章节中我们会讲述如何部署与使用这套DNS系统。
1. - 外部系统访问service的问题
为了更加深刻的理解和掌握Kubernetes，我们需要弄明白kubernetes里面的“三种IP”这个关键问题，这三种IP 分别如下：
- Node IP： Node（物理主机）的IP地址
- Pod IP：Pod的IP地址
- Cluster IP： Service 的IP地址
1. - 服务类型
对一些应用（如 Frontend）的某些部分，可能希望通过外部（Kubernetes 集群外部）IP 地址暴露 Service。

Kubernetes ServiceTypes 允许指定一个需要的类型的 Service，默认是 ClusterIP 类型。

Type 的取值以及行为如下：
- ClusterIP：通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的 ServiceType
- NodePort：通过每个 Node 上的 IP 和静态端口（NodePort）暴露服务。NodePort 服务会路由到 ClusterIP 服务，这个 ClusterIP 服务会自动创建。通过请求 :，可以从集群的外部访问一个 NodePort 服务
- LoadBalancer：使用云提供商的负载均衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务。
- ExternalName：通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容（例如， foo.bar.example.com）。没有任何类型代理被创建，这只有 Kubernetes 1.7 或更高版本的 kube-dns 才支持。
  - 一个Node Port 的简单示例
```
apiVersion: vl
kind: Service
metadata;
  name:	tomcat-service
spec:
  type: NodePort
  ports:
    - port:	8080
    nodePort: 31002
  selector:
    tier: frontend
```
Volume 存储卷
- 简述
我们知道默认情况下容器的数据都是非持久化的，在容器消亡以后数据也跟着丢失，所以Docker提供了Volume机制以便将数据持久化存储。类似的，Kubernetes提供了更强大的Volume机制和丰富的插件，解决了容器数据持久化和容器间共享数据的问题
1. - Volume
    目前，Kubernetes支持以下Volume类型：
```
- emptyDir
- hostPath
- gcePersistentDisk
- awsElasticBlockStore
- nfs
- iscsi
- flocker
- glusterfs
- rbd
- cephfs
- gitRepo
- secret
- persistentVolumeClaim
- downwardAPI
- azureFileVolume
- vsphereVolume
- flexvolume    
```
注意，这些volume并非全部都是持久化的，比如emptyDir、secret、gitRepo等，这些volume会随着Pod的消亡而消失
1. - PersistentVolume
对于持久化的Volume，PersistentVolume (PV)和PersistentVolumeClaim (PVC)提供了更方便的管理卷的方法：PV提供网络存储资源，而PVC请求存储资源。这样，设置持久化的工作流包括配置底层文件系统或者云数据卷、创建持久性数据卷、最后创建claim来将pod跟数据卷关联起来。PV和PVC可以将pod和数据卷解耦，pod不需要知道确切的文件系统或者支持它的持久化引擎。
1. - PV
    PersistentVolume（PV）是集群之中的一块网络存储。跟 Node 一样，也是集群的资源。PV 跟 Volume (卷) 类似，不过会有独立于 Pod 的生命周期。比如一个本地的PV可以定义为
```
kind: PersistentVolume
apiVersion: v1
metadata:
  name: grafana-pv-volume
  labels:
    type: local
spec:
  storageClassName: grafana-pv-volume
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  hostPath:
    path: "/data/volume/grafana"
```
  pv的访问模式有三种
  - 第一种，ReadWriteOnce：是最基本的方式，可读可写，但只支持被单个Pod挂载。
  - 第二种，ReadOnlyMany：可以以只读的方式被多个Pod挂载。
  - 第三种，ReadWriteMany：这种存储可以以读写的方式被多个Pod共享。不是每一种存储都支持这三种方式，像共享方式，目前支持的还比较少，比较常用的是NFS。在PVC绑定PV时通常根据两个条件来绑定，一个是存储的大小，另一个就是访问模式
2. - StorageClass
上面通过手动的方式创建了一个NFS Volume，这在管理很多Volume的时候不太方便。Kubernetes还提供了StorageClass来动态创建PV，不仅节省了管理员的时间，还可以封装不同类型的存储供PVC选用。
- Ceph RBD的例子：
```
apiVersion: storage.k8s.io/v1beta1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/rbd
parameters:
  monitors: 10.16.153.105:6789
  adminId: kube
  adminSecretName: ceph-secret
  adminSecretNamespace: kube-system
  pool: kube
  userId: kube
  userSecretName: ceph-secret-user
```
1. - PVC
PV是存储资源，而PersistentVolumeClaim (PVC) 是对PV的请求。PVC跟Pod类似：Pod消费Node的源，而PVC消费PV资源；Pod能够请求CPU和内存资源，而PVC请求特定大小和访问模式的数据卷。
```
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: grafana-pvc-volume
  namespace: "monitoring"
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: grafana-pv-volume
```
PVC可以直接挂载到Pod中：
```
kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: grafana-pvc-volume
```
1. - 其他volume 说明
  - NFS
    NFS 是Network File System的缩写，即网络文件系统。Kubernetes中通过简单地配置就可以挂载NFS到Pod中，而NFS中的数据是可以永久保存的，同时NFS支持同时写操作。
```
volumes:
- name: nfs
  nfs:
    # FIXME: use the right hostname
    server: 10.254.234.223
    path: "/data"
```
  - emptyDir
  如果Pod配置了emptyDir类型Volume， Pod 被分配到Node上时候，会创建emptyDir，只要Pod运行在Node上，emptyDir都会存在（容器挂掉不会导致emptyDir丢失数据），但是如果Pod从Node上被删除（Pod被删除，或者Pod发生迁移），emptyDir也会被删除，并且永久丢失。
```
apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    emptyDir: {}
```
namespace
- 简述
  
  在一个Kubernetes集群中可以使用namespace创建多个“虚拟集群”，这些namespace之间可以完全隔离，也可以通过某种方式，让一个namespace中的service可以访问到其他的namespace中的服务，我们在CentOS中部署kubernetes1.6集群的时候就用到了好几个跨越namespace的服务，比如Traefik ingress和kube-systemnamespace下的service就可以为整个集群提供服务，这些都需要通过RBAC定义集群级别的角色来实现。
- 哪些情况下适合使用多个namesapce
  
  因为namespace可以提供独立的命名空间，因此可以实现部分的环境隔离。当你的项目和人员众多的时候可以考虑根据项目属性，例如生产、测试、开发划分不同的namespace。
- Namespace使用，获取集群中有哪些namespace
  
  kubectl get ns
  
  集群中默认会有default和kube-system这两个namespace。
  
  在执行kubectl命令时可以使用-n指定操作的namespace。
  
  用户的普通应用默认是在default下，与集群管理相关的为整个集群提供服务的应用一般部署在kube-system的namespace下，例如我们在安装kubernetes集群时部署的kubedns、heapseter、EFK等都是在这个namespace下面。
  
  另外，并不是所有的资源对象都会对应namespace，node和persistentVolume就不属于任何namespace。

CI/CD 部署应用

流程说明

应用构建和发布流程说明。

用户向Gitlab提交代码，代码中必须包含Dockerfile
将代码提交到远程仓库
用户在发布应用时需要填写git仓库地址和分支、服务类型、服务名称、资源数量、实例个数，确定后触发Jenkins自动构建
Jenkins的CI流水线自动编译代码并打包成docker镜像推送到Harbor镜像仓库
Jenkins的CI流水线中包括了自定义脚本，根据我们已准备好的kubernetes的YAML模板，将其中的变量替换成用户输入的选项
生成应用的kubernetes YAML配置文件
更新Ingress的配置，根据新部署的应用的名称，在ingress的配置文件中增加一条路由信息
更新PowerDNS，向其中插入一条DNS记录，IP地址是边缘节点的IP地址。关于边缘节点，请查看边缘节点配置
Jenkins调用kubernetes的API，部署应用

kubernetes 功能介绍

kubernetes 的马洛斯需求

kubernetes 架构图

kubernetes 主要基本概念和术语

master

node

pod：

label（标签）

Replication Contoller

简述：

Deployment

简述

典型的应用场景包括：

一个简单的nginx 应用可以定义为：

Horizontal Pod Autoscaler

简述：

Metrics支持

Service

kubernetes 的服务发现机制

环境变量

DNS

外部系统访问service的问题

服务类型

Volume 存储卷

namespace

CI/CD 部署应用

流程说明

猜你喜欢