kubernetes 各个组件用途

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的选主功能,

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。

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） 

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来实现，

   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）

   资源供应：

        静态模式：集群管理员手工创建许多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包括不同的参数设置，某些参数可以不显示设定

   创建一个sc

StatefulSet

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

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

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

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

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

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

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

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

Volume（存储卷）

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

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

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

NodeSelector 定向调度

taints和tolerations（污点和容忍）

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

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

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

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

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

proxy API 代理 

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

容器健康检查

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

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时的身份鉴权过程

 secret私密凭据 

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

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

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

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

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

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

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

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。