kubernetes 各个组件用途

1. master上的etcd，kube-apiserver，kube-controller-manager kube-scheduler

   1. etcd作为kubernetes集群的主数据库，在安装kubernetes各服务之前需要首先安装和启动

   2. kube-apiserver服务：提供kubernetes各类资源对象的增，删，改，查及watch等HTTPRest接口，成为集群内各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。提供了资源对象的唯一操作入口，其他所有组件都必须通过它提供的API来操作资源数据 

      还提供特殊rest接口-kubernetes proxy API接口，把收到rest请求转发到某个node上的kubelet守护进程的rest端口上，由该kubelet进程负责响应

      proxy API里关于Node的相关接口，该接口的rest路径为

      /api/v1/proxy/nodes/{name}/pods/  

      如果想要访问pod里某个容器提供的服务

      /api/v1/proxy/namespaces/{namespace}/pod/{name}/{path:*}

      kubernetes集群之外访问某个pod服务时，可以用proxy API实现，这种场景用于管理目的

   3. 查看api版本信息：curl localhost：8080/api/v1

   4. kube-controller-manager服务：负责执行各种控制器，主要有：endpoint-controller：定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的。负责集群内的node，pod副本，服务端点，命名空间，服务账号（serviceaccount），资源定额管理。

      replication-controller：定期关联replicationController和pod，保证replicationController定义的复制数量与实际运行pod的数量总是一致的。

   5. kube-scheduler服务：负责调度pod

   6. kube-scheduler以及kube-controller-manager高可用则是在两台master配置文件设置leader-elect参数，kube-scheduer和kube-controller-manager使用一主多从的高可用方案,依赖Etcd实现scheduler和controller-manager的选主功能,

2. node上的kubelet，kube-proxy服务

   1. kubelet服务：负责Pod对应的容器的创建，启停，与Master密切协作，实现集群管理的基本功能ubelet是Master API Server和Minion之间的桥梁，接收Master API Server分配给它的commands和work，与持久性键值存储etcd、file、server和http进行交互，读取配置信息。

   2. kube-proxy服务：Kube-proxy是一个简单的网络代理和负载均衡器，它的作用主要是负责Service的实现，将某个service的访问请求转发到后端的多个pod实例上。在运行过程中会动态创建于service相关的iptables规则，这些规则实现了将访问服务的请求转发到后端pod。

3. Kube-dns介绍

   Kube-dns用来为kubernetes service分配子域名，在集群中可以通过名称访问service；通常kube-dns会为service赋予一个名为“service名称.namespace.svc.cluster.local”的A记录，用来解析service的clusterip。

   1. Kubedns

      1. 接入SkyDNS，为dnsmasq提供查询服务。
      2. 替换etcd容器，使用树形结构在内存中保存DNS记录。
      3. 通过K8S API监视Service资源变化并更新DNS记录。
      4. 服务10053端口。

   2. Dnsmasq

      1. Dnsmasq是一款小巧的DNS配置工具。
      2. 在kube-dns插件中的作用是：
      3. Dockerfile在GitHub上Kubernetes组织的contrib仓库中，位于dnsmasq目录下。
      4. 在kube-dns插件的编排文件中可以看到，dnsmasq通过参数–server=127.0.0.1:10053指定upstream为kubedns。

      5. 1通过kubedns容器获取DNS规则，在集群中提供DNS查询服务

         2提供DNS缓存，提高查询性能

         3降低kubedns容器的压力、提高稳定性

   3. kube-dns默认是根据服务名解析域名对应ip 

   4. 如果想要根据pod hostname 解析对应ip，构建service的时候，将clusterIP设置为None（headless service） 

4. PV PVC，storageclass详解（pv和pvc绑定通过label决定或者storageClassName）

   1. PV

      是对底层网络共享存储的抽象，将共享存储定义为一种资源，比如node是容器应用消费的资源，包括存储能力，访问模式，存储类型，回收策略，后端存储类型等关键信息的设置。

      pv定义资源容量是多少，pvc定义pod使用多少容量

      kubectl get pv 显示可用pv的容量多少。

      存储能力：存储设备具备的能力，现在支持存储空间的设置（storage=xx）

      访问模式：对pv进行访问模式的设置，rwo，单个node挂载

      存储类别：pv可以设定其存储的类别（class），通过storageclassname参数指定一个storageclass资源对象的名称。具有特定类别的pv只能与请求该类别的pvc进行绑定，未设定类别的pv则只能对不请求任何类别的pvc绑定。

      回收策略：1.保留（retain）2回收空间（recycle）简单清除文件的操作 3删除（delete）

      kubernetes 支持的pv类型如下和PV的挂载参数

      将PV挂载到一个node上时，根据后端存储的特点，可能需要设置额外的挂载参数，目前可以通过在PV的定义中，设置一个名为volume.beta.kubernetes.io/mount-options: "discard"的annotations来实现，

      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: rancher-pv
        labels:
          pv: rancher-pv
      spec:
        capacity:
          storage: 1Gi
        volumeMode: Filesystem
        accessModes:
        - ReadWriteOnce
        persistentVolumeReclaimPolicy: Recycle
        rbd:
          monitors:
            - 10.10.30.30:6789,10.10.30.31:6789,10.10.30.32:6789
          pool: zhaoqi
          #首先要创建好镜像，用rbd create zhao-test --size 1024
          image: zhao-test
          user: admin
          secretRef:
            name: ceph-rancher
          fsType: xfs
          readOnly: false

      

      pv生命周期的各个阶段（phase）

              Available：可用状态，还未与某个pvc绑定

              Bound：已于某个pvc绑定

              Released：绑定的pvc已经删除资源已释放，但没有被集群回收

              Failed：自动资源回收失败

   2. PVC 

      用户对于存储资源的一个申请，就想pod消费node的资源一样，pvc消费pv资源，pvc可以申请特定的存储空间和访问模式

      PVC的yaml文件用法

      申请8Gi存储空间，访问模式为readwriteonce，pv选择条件为包含标签 release=stable并且包含条件为environment，存储类别为slow（系统中已经存在名为slow的storageclass）

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: rancher-pvc
        namespace: rancher
      spec:
        accessModes:
        - ReadWriteOnce
        storageClassName: rancher-sc
        resources:
          requests:
            storage: 10Gi

      

      资源供应：

           静态模式：集群管理员手工创建许多pv，在定义pv时需要将后端存储的特性进行设置

           动态模式：集群管理员无须手工创建pv，通过storageclass的设置对后端存进行描述，标记为某种类型（class），此时要求pvc对存储的类型进行声明，系统将自动完成pv的创建及与pvc的绑定

           资源使用： pod使用volume的定义，将pvc挂载到容器内的某个路径进行使用，volume的类型为pvc，多个pod可以挂载同一个pvc。一旦用户删除了pvc，与之绑定的pv将根据其默认的回收策略delete也会被删除，如果需要保留pv（用户数据），则在动态绑定成功后，用户将系统自动生成pv的回收策略从delete改成retain。

           资源绑定：pv一旦绑定到某个pvc上，就被这个pvc独占，不能再与其他pvc进行绑定。然后用户的应用就可以使用这个pvc了，当pvc申请的存储空间比pv的少时，整个pv的空间都能够为pvc所用，可能造成资源的浪费。如果资源供应使用的是动态模式，则系统在为pvc找到合适的storageclass后，将自动创建一个pv并完成与pvc的绑定

   3. storageclass

          作为对存储资源的抽象定义，标记存储资源的特性和性能，自动完成pv的创建和绑定，实现了动态资源供应

          主要包括名称，后端存储的提供者和后端存储的相关参数配置，storageclass一旦被创建出来，将无法修改，如需更改，则只能删除原storageclass的定义重建。

          资源提供者（provisioner）：描述存储资源的提供者，也可以看作后端存储驱动

          参数（parameters）：后端存储资源提供者的参数设置，不同的provision包括不同的参数设置，某些参数可以不显示设定 

          设置默认storageclass 2种方式

   • 第一种 

     首先要开启#kube-apiserver命令行参数--admission-controller=...,DefaultStorageClass

   • 第二种 

     在yaml文件添加 

     annotations:

       storageclass.beta.kubernetes.io/is-default-class="true"

     使用命令行 

       kubectl patch storageclass ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' 

     apiVersion: storage.k8s.io/v1
     kind: StorageClass
     metadata:
       name: rancher-sc
       #在kube-apiserver命令行参数--admission-controller=...,DefaultStorageClass
       annotation:
         storageclass.beta.kubernetes.io/is-default-class: "true"    
     provisioner: kubernetes.io/rbd
     parameters:
       monitors: 10.10.30.30:6789,10.10.30.31:6789,10.10.30.32:6789
     #adminId | userId 这里需要指定两种 Ceph 角色 admin 和其他 user，admin 角色默认已经有了，其他 user 可以去 Ceph 集群创建一个并赋对应权限值，如果不创建，也可以都指定为 admin
       adminId: admin
     #adminSecretName 为上边创建的 Ceph 管理员 admin 使用的 ceph-rancher
       adminSecretName: ceph-rancher
     #adminSecretNamespace 管理员 secret 使用的命名空间，默认 default，如果修改为其他的话，需要修改 secret.yaml 增加 namespace: other-namespace
       adminSecretNamespace: kube-system
       pool: zhaoqi
       userId: admin #与adminId相同就行
       #需要在rancher 这个ns下创建ceph-rancher这个密钥，否则无法pod使用pvc时，出现密钥问题
       userSecretName: ceph-rancher #使用userId映射Ceph RBD图像，与pvc在同一个ns下，与adminsecretName相同就行
       fsType: ext4
       imageFormat: "2"
       imageFeatures: "layering"

   • 创建一个sc

5. StatefulSet

      StatefulSet里的每个pod都有稳定，唯一的网络标识，可以用来发现集群内的其他成员，假设

      StatefulSet的名字叫kafka，那么第一个pod叫kafka-0，第二个叫kafka-1

      StatefulSet控制的Pod副本的启停顺序是受控的，操作第n个pod时，前n-1个pod已经运行且准备好的状态

      StatefulSet里的pod采用稳定的持久化 存储卷，通过pv/pvc来实现，删除pod时默认不会删除与StatefulSet相关的存储卷

6. job  启动一个批处理任务，也是管理pod的自动控制器

      job所控制的pod是短暂的，可以看做一组docker容器，每个容器仅运行一次，当job控制的所有pod运行结束时，对应的job也就结束了。

7. HPA（pod横向自动扩容，与RC，deployment一样）

       通过追踪分析RC控制的所有目标pod的负载变化情况，来确定是否需要针对性地调整目标pod的副本数，通过定期查询pod的资源利用率（cpu）来调整pod的数目。

8. Volume（存储卷）

       volume是pod中能够被多个容器访问的共享目录，k8s volume与docker的volume类似，但不能等价。首先k8s的volume定义在pod上，然后供pod里的容器去挂载到具体的文件目录下（相当于定义存储卷，而docker是定义挂载点），其次，k8s中的volume与pod的生命周期相同，但与容器生命周期不同，当容器终止或者重启时，volume中的数据也不会丢失。

9. ConfigMap（初始化所用到的东西-脚本，所要）

       以一个或多个key：value的形式保存在k8s系统中供应用使用，既可以用于表示一个变量的值(app=info)，也可以用于表示一个完整配置文件的内容（server.xml=<?xml...>...）

       生成为容器内的环境变量

       设置容器启动命令的启动参数（需设置为环境变量）

       以Volume挂载的方式将configmap中的内容挂载为容器内部的文件或目录

       configmap注意点 subpath，items 

   （k8s configMap 中 subPath 字段和 items 字段 - 拾月凄辰 - 博客园）

          subpath 将文件挂载到某个目录，但希望只是挂载该文件，不要影响挂载目录下的其他文件。同时将一个volume下的多个目录，挂载到不同的挂载点上。

   1. 从文件创建

      kubectl create configmap cs（名字） --from-file=server.xml

   2. 从目录创建

      kubectl create configmap cmdir --from-file=configfiles

   3. 使用--from-literal参数进行创建

      kubectl create configmap csenv --from-literal=loglevel=info --from-literal=appdatadir=/var/data

   4. 通过volume方式使用ConfigMap

10. NodeSelector 定向调度

     

11. taints和tolerations（污点和容忍）

        在node上设置一个或多个taint之后，除非pod明确声明能够容忍这些污点（taints），否则无法再这些node上运行，toleration是pod的属性，让pod能够运行在标注taint的node上。

        kubectl taint nodes times03 key=value:NoSchedule(除非pod容忍这个taint，否则不会调度到times03)

12. DaemonSet:在每个Node上调度一个pod

    主要用于日志采集（fluentd），性能监控程序（例如calico）

13. service  

    要解决pod地址可变的问题，由于pod随时可能故障，并可能在其他节点上被重启，用一个service代表提供某一类功能（通过标签来筛选）的一些pod，并分配不随pod位置变化而改变的虚拟访问地址（cluster ip），这个地址并不绑定到任何借口，将作为访问服务的抽象地址，访问该地址会被映射到pod的实际地址，实际上通过kube-proxy进程，负责将到某个service的访问给代理或者负载均衡到具体的pod上。

    1. 3种工作模式   userspace，iptables，ipvs 现在使用后2种

    2. 有2种方法可以用于暴露服务

       1. service的VIP：也就是cluster IP

       2. service的DNS： 服务名.命名空间.svc.cluster.local这条DNS记录访问

       3. 关系是这样service -> endpoints -> pods

       4. service比较重要的一个点sessionAffinity 绑定同一个客户端ip到同一个pod上

          sessionAffinity: ClientIP

14. proxy API 代理 

    kubernetes proxy API也有service的proxy接口，用法用pod差不多，就是把pods换成services

15. 容器健康检查

    1. livenessProbe

       livenessProbe：
         exec：
           command：
           - cat 
           - /tmp/health
         initialDelaySeconds: 15
         timeoutSeconds: 1
        	如果该命令返回值为0，则表明容器处于健康状态，否则表明容器处于不健康状态
       实现容器的http检查，kubelet发送一个http请求到本地主机和端口及指定的路径，检查容器的健康状况

    2. readinessProve

       readinessProve:
             failureThreshold: 8
             httpGet:
               host: 127.0.0.1
               path: /healthz
               port: 6443
               scheme: HTTPS
             initialDelaySeconds: 15
             timeoutSeconds: 15

16. service account 

         一个service account对象里面可以包括多个不同的secret对象，secret从属于service account资源对象，属于service account的一部分。一个secret由ns，token，ca组成

       查看系统中service account对象（服务账户），看到一个名为default的service account对象

       包含一个名为 default-token-4rkqn的secret，这个secret同时是mountable secrets，表明他是需要被mount到pod上的

        查看 default-token-4rkqn的tokens内容，也就是查看secret的内容 

       每个namespaces下有一个名为default的默认的service account对象，而名为tokens的当做volume被mount到pod里的secret，当pod启动时，这个secret会自动被mount到pod的指定目录下，用来协助完成pod中的进程访问API Server时的身份鉴权过程。

       secret：用API Server私钥创建一个token，并用该token，CA证书及namespace名称等3个信息产生一个新的secret对象。然后放入刚才的service account中，

    每个ns下有一个名为default的默认的service account对象，这个service account里面有一个名为tokens的可以当作volume一样被mount到pod里的secret，当pod启动时，这个secret会自动被mount到pod的指定目录下，用来协助完成pod中的进程访问api server时的身份鉴权过程

    

17.  secret私密凭据 

    secret 3种类型 

      docker-registry：专门为下拉镜像用的

      tls： 配置证书和私钥

      generic： 通用secret

    主要作用是保管私密数据，比如密码，oauth tokens，ssh keys等信息。

    data域的各子域的值必须为base64编码值，一旦secret被创建，通过3种方式使用它

    （1）创建pod是，通过为pod指定service account来自动使用该secret

    （2）通过挂载该secret到pod来使用它

    （3）docker镜像下载时使用，通过指定pod的spc.imagepullsecrets来引用它

• 第一种

  kubectl create secret generic ceph-rancher --type="ceph.com/rbd" --from-literal=key='AQBuH9pcH8ClGBAALMHLYr5k0pbT2gbRlWdodw==' --namespace=kube-system

• 第二种，如何将secret通过挂载的方式添加到pod的vulume中

  apiVersion: v1
  kind: Secret
  metadata:
    name: ceph-rancher
    namespace: kube-system
  type: "ceph.com/rbd"
  data:
    #ceph base64转换后的key
    key: QVFCdUg5cGNIOENsR0JBQUxNSExZcjVrMHBiVDJnYlJsV2RvZHc9PQo=

  

  secret保管其他系统的敏感信息（数据库的用户名和密码），并以mount的方式将secret挂载到Container中，然后通过访问容器目录中的文件的方式获取敏感信息，一旦这个pod被调度，则kubelet将试着获取secret的值。一旦secret被pod获取，则kubelet将创建并mount包含secret的volume。只有所有volume被mount后，pod中的Container才会被启动 

1. ingress策略：在service 之前加了一层ingress

      Ingress 的实现分为两个部分 Ingress Controller 和 Ingress  

         Ingress Controller 是流量的入口，是一个实体软件， 一般是Nginx 和 Haproxy 

         Ingress 描述具体的路由规则 

             简单说： Ingress 描述路由规则， Ingress Controller 实时实现规则

      Ingress Contronler 通过与 Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，然后读取它，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段 Nginx 配置，再写到 Nginx-ingress-control的 Pod 里，这个 Ingress Contronler 的pod里面运行着一个nginx服务，控制器会把生成的nginx配置写入/etc/nginx.conf文件中，然后 reload 一下 使用配置生效。以此来达到域名分配置及动态更新的问题。

   1. 转发到单个后端服务上 

      因为转发到后端的唯一service上，无需定义rule，对ingress controller的访问请求都将被转发到myweb:8080这个服务上

   2. 同一域名下，不同的URL路径被转发到不同的服务上 

      对mywebsite.com/web的访问请求将被转发到web-service：80服务上

      对mywebsite.com/api的访问请求将被转发到apiservice：80801服务上

   3. 不同的域名被转发到不同的服务上

      一个网址通过不同的域名或虚拟主机名提供不同的服务的场景，foo.bar.com域名由service1提供服务，bar.foo.com域名由service2提供服务

   4. 不使用域名的转发规则

      网站不使用域名直接提供服务的场景，通过任意一台运行ingress-controller的node都能访问到后端的服务。（访问方式 ingress-controller-ip/demo请求转发到webapp：8080/demo）使用无域名的ingress转发规则时，将默认禁用非安全HTTP，强制开启HTTPS。

2.  

     ​​​​​​