k8s

https://kubernetes.io/docs/tutorials/kubernetes-basics/

Kubernetes集群包含有节点代理kubelet和Master组件(APIs, scheduler, etc)，一切都基于分布式的存储系统

总体结构

 

开发者开发一个应用后，打包Docker镜像，上传到Docker registry；而后编写一个yaml部署描述文件。开发者经过kubectl（或其它应用），将部署描述文件提交到API server，API server将部署需求更新到etcd。etcd在K8s管理结点中的做用至关于数据库，其它组件提交到API server的数据都存储于etcd。API server很是轻量，并不会直接去建立或管理Pod等资源，在多数场景下甚至不会去主动调用其它的K8s组件发出指令。其它组件经过创建和API server的长链接，监视关心的对象，监视到变化后，执行所负责的操做。如图所示，Controller Manager中的控制器监视到新的部署描述后，根据部署描述，建立ReplicaSet、Pod等资源。Scheduler监视到新的Pod资源后，结合集群的资源状况，选定一或多个工做结点运行Pod。工做结点上的Kubelet监视到有Pod被计划在本身的结点后，向Docker等Container runtime发出启动容器的指令，Docker engineer将按照指令从Docker registy拉取镜像，而后启动并运行容器

如下是摘自 凌风探梅的总结

.什么是kubernetes

　　首先，他是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提升了大规模容器集群管理的便捷性。

　　Kubernetes是一个完备的分布式系统支撑平台，具备完备的集群管理能力，多扩多层次的安全防御和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes提供完善的管理工具，涵盖了包括开发、部署测试、运维监控在内的各个环节。

Kubernetes中，Service是分布式集群架构的核心，一个Service对象拥有以下关键特征：

• 拥有一个惟一指定的名字
• 拥有一个虚拟IP（Cluster IP、Service IP、或VIP）和端口号
• 可以体统某种远程服务能力
• 被映射到了提供这种服务能力的一组容器应用上

　　Service的服务进程目前都是基于Socket通讯方式对外提供服务，好比Redis、Memcache、MySQL、Web Server，或者是实现了某个具体业务的一个特定的TCP Server进程，虽然一个Service一般由多个相关的服务进程来提供服务，每一个服务进程都有一个独立的Endpoint（IP+Port）访问点，但Kubernetes可以让咱们经过服务链接到指定的Service上。有了Kubernetes内奸的透明负载均衡和故障恢复机制，无论后端有多少服务进程，也无论某个服务进程是否会因为发生故障而从新部署到其余机器，都不会影响咱们队服务的正常调用，更重要的是这个Service自己一旦建立就不会发生变化，意味着在Kubernetes集群中，咱们不用为了服务的IP地址的变化问题而头疼了。

　　容器提供了强大的隔离功能，全部有必要把为Service提供服务的这组进程放入容器中进行隔离。为此，Kubernetes设计了Pod对象，将每一个服务进程包装到相对应的Pod中，使其成为Pod中运行的一个容器。为了创建Service与Pod间的关联管理，Kubernetes给每一个Pod贴上一个标签Label，好比运行MySQL的Pod贴上name=mysql标签，给运行PHP的Pod贴上name=php标签，而后给相应的Service定义标签选择器Label Selector，这样就能巧妙的解决了Service于Pod的关联问题。

　　在集群管理方面，Kubernetes将集群中的机器划分为一个Master节点和一群工做节点Node，其中，在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，而且都是全自动完成的。Node做为集群中的工做节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的kubelet、kube-proxy服务进程，这些服务进程负责Pod的建立、启动、监控、重启、销毁以及实现软件模式的负载均衡器。

　　在Kubernetes集群中，它解决了传统IT系统中服务扩容和升级的两大难题。你只需为须要扩容的Service关联的Pod建立一个Replication Controller简称（RC），则该Service的扩容及后续的升级等问题将迎刃而解。在一个RC定义文件中包括如下3个关键信息。

• 目标Pod的定义
• 目标Pod须要运行的副本数量（Replicas）
• 要监控的目标Pod标签（Label）

　　在建立好RC后，Kubernetes会经过RC中定义的的Label筛选出对应Pod实例并实时监控其状态和数量，若是实例数量少于定义的副本数量，则会根据RC中定义的Pod模板来建立一个新的Pod，而后将新Pod调度到合适的Node上启动运行，知道Pod实例的数量达到预约目标，这个过程彻底是自动化。

　　

　Kubernetes优点:

　　　　- 容器编排

　　　　- 轻量级

　　　　- 开源

　　　　- 弹性伸缩

　　　　- 负载均衡

 

Kubernetes主要由如下几个核心组件组成：

• etcd保存了整个集群的状态；
• apiserver提供了资源操做的惟一入口，并提供认证、受权、访问控制、API注册和发现等机制；
• controller manager负责维护集群的状态，好比故障检测、自动扩展、滚动更新等；
• scheduler负责资源的调度，按照预约的调度策略将Pod调度到相应的机器上；
• kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
• Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
• kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

每一个API对象都有3大类属性：元数据metadata、规范spec和状态status

pod文件

# yaml格式的pod定义文件完整内容：
apiVersion: v1       #必选，版本号，例如v1
kind: Pod       #必选，Pod
metadata:       #必选，元数据
  name: string       #必选，Pod名称
  namespace: string    #必选，Pod所属的命名空间
  labels:      #自定义标签
    - name: string     #自定义标签名字
  annotations:       #自定义注释列表
    - name: string
spec:         #必选，Pod中容器的详细定义
  containers:      #必选，Pod中容器列表
  - name: string     #必选，容器名称
    image: string    #必选，容器的镜像名称
    imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像，不然下载镜像，Nerver表示仅使用本地镜像
    command: [string]    #容器的启动命令列表，如不指定，使用打包时使用的启动命令
    args: [string]     #容器的启动命令参数列表
    workingDir: string     #容器的工做目录
    volumeMounts:    #挂载到容器内部的存储卷配置
    - name: volumestring     #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
      mountPath: string    #存储卷在容器内mount的绝对路径，应少于512字符
      readOnly: boolean    #是否为只读模式
    ports:       #须要暴露的端口库号列表
    - name: string     #端口号名称
      containerPort: int   #容器须要监听的端口号
      hostPort: int    #容器所在主机须要监听的端口号，默认与Container相同
      protocol: string     #端口协议，支持TCP和UDP，默认TCP
    env:       #容器运行前需设置的环境变量列表
    - name: string     #环境变量名称
      value: string    #环境变量的值
    resources:       #资源限制和请求的设置
      limits:      #资源限制的设置
        cpu: string    #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
        memory: string     #内存限制，单位能够为Mib/Gib，将用于docker run --memory参数
      requests:      #资源请求的设置
        cpu: string    #Cpu请求，容器启动的初始可用数量
        memory: string     #内存清楚，容器启动的初始可用数量
    livenessProbe:     #对Pod内个容器健康检查的设置，当探测无响应几回后将自动重启该容器，检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法便可
      exec:      #对Pod容器内检查方式设置为exec方式
        command: [string]  #exec方式须要制定的命令或脚本
      httpGet:       #对Pod内个容器健康检查方法设置为HttpGet，须要制定Path、port
        path: string
        port: number
        host: string
        scheme: string
        HttpHeaders:
        - name: string
          value: string
      tcpSocket:     #对Pod内个容器健康检查方式设置为tcpSocket方式
         port: number
       initialDelaySeconds: 0  #容器启动完成后首次探测的时间，单位为秒
       timeoutSeconds: 0   #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
       periodSeconds: 0    #对容器监控检查的按期探测时间设置，单位秒，默认10秒一次
       successThreshold: 0
       failureThreshold: 0
       securityContext:
         privileged:false
    restartPolicy: [Always | Never | OnFailure]#Pod的重启策略，Always表示一旦无论以何种方式终止运行，kubelet都将重启，OnFailure表示只有Pod以非0退出码退出才重启，Nerver表示再也不重启该Pod
    nodeSelector: obeject  #设置NodeSelector表示将该Pod调度到包含这个label的node上，以key：value的格式指定
    imagePullSecrets:    #Pull镜像时使用的secret名称，以key：secretkey格式指定
    - name: string
    hostNetwork:false      #是否使用主机网络模式，默认为false，若是设置为true，表示使用宿主机网络
    volumes:       #在该pod上定义共享存储卷列表
    - name: columestring     #共享存储卷名称 （volumes类型有不少种）
      emptyDir: {}     #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
      hostPath: string     #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
        path: string     #Pod所在宿主机的目录，将被用于同期中mount的目录
      secret:      #类型为secret的存储卷，挂载集群与定义的secre对象到容器内部
        scretname: string  
        items:     
        - key: string
          path: string
      configMap:     #类型为configMap的存储卷，挂载预约义的configMap对象到容器内部
        name: string
        items:
        - key: string
          path: string    

Node

• 每一个Node节点都运行着如下一组关键进程
• kubelet：负责对Pod对于的容器的建立、启停等任务
• kube-proxy：实现Kubernetes Service的通讯与负载均衡机制的重要组件
• Docker Engine（Docker）：Docker引擎，负责本机容器的建立和管理工做

复制控制器（Replication Controller，RC）

Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本，是实现弹性伸缩、动态扩容和滚动升级的核心。

随后能够经过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象，Kubernetes经过这种方式实现了相似SQL的简单又通用的对象查询机制

 

　Label Selector在Kubernetes中重要使用场景以下:

 

　　1.kube-Controller进程经过资源对象RC上定义Label Selector来筛选要监控的Pod副本的数量，从而实现副本数量始终符合预期设定的全自动控制流程

　　2.kube-proxy进程经过Service的Label Selector来选择对应的Pod，自动创建起每一个Service岛对应Pod的请求转发路由表，从而实现Service的智能负载均衡

　　3.经过对某些Node定义特定的Label，而且在Pod定义文件中使用Nodeselector这种标签调度策略，kuber-scheduler进程能够实现Pod”定向调度“的特性

 

Label

Label是Replication Controller和Service运行的基础，两者经过Label来进行关联Node上运行的Pod。

Service

　Node IP：Node节点的IP地址

　Pod IP： Pod的IP地址

　Cluster IP：Service的IP地址

Service是定义一系列Pod以及访问这些Pod的策略的一层抽象。Service经过Label找到Pod组

2个后台Pod，定义后台Service的名称为‘backend-service’，

lable选择器为（tier=backend, app=myapp）。backend-service 的Service会完成以下两件重要的事情：

1.会为Service建立一个本地集群的DNS入口，所以前端Pod只须要DNS查找主机名为 ‘backend-service’，就可以解析出前端应用程序可用的IP地址。

2.如今前端已经获得了后台服务的IP地址，可是它应该访问2个后台Pod的哪个呢？Service在这2个后台Pod之间提供透明的负载均衡，会将请求分发给其中的任意一个（以下面的动画所示）。经过每一个Node上运行的代理（kube-proxy）完成.

Deployment

Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新,只须要在Deployment中描述你想要的目标状态是什么，Deployment controller就会帮你将Pod和Replica Set的实际状态改变到你的目标状态

一个典型的用例以下：

• 使用Deployment来建立ReplicaSet。ReplicaSet在后台建立pod。检查启动状态，看它是成功仍是失败。
• 而后，经过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会建立一个新的ReplicaSet，Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。
• 若是当前状态不稳定，回滚到以前的Deployment revision。每次回滚都会更新Deployment的revision。
• 扩容Deployment以知足更高的负载。
• 暂停Deployment来应用PodTemplateSpec的多个修复，而后恢复上线。
• 根据Deployment 的状态判断上线是否hang住了。
• 清除旧的没必要要的ReplicaSet。

Ingress

 service和pod的IP仅可在集群内部访问。集群外部的请求须要经过负载均衡转发到service在Node上暴露的NodePort上，而后再由kube-proxy将其转发给相关的Pod。而Ingress就是为进入集群的请求提供路由规则的集合

Ingress能够给service提供集群外部访问的URL、负载均衡、SSL终止、HTTP路由等。为了配置这些Ingress规则，集群管理员须要部署一个Ingress controller，它监听Ingress和service的变化，并根据规则配置负载均衡并提供访问入口。

apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test spec: rules: - host: foo.bar.com http: paths: - path: /foo backend: serviceName: s1 servicePort: 80 - path: /bar backend: serviceName: s2 servicePort: 80

Volume

Secrets

 

 echo -n "root" | base64
cm9vdA==

 

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: MWYyZDFlMmU2N2Rm
  username: YWRtaW4=

建立好secret以后，有两种方式来使用它：

• 以Volume方式
• 以环境变量方式

将Secret挂载到Volume中

apiVersion: v1 kind: Pod metadata: labels: name: db name: db spec: volumes: - name: secrets secret: secretName: mysecret 建立的secrect名字 containers: - image: gcr.io/my_project_id/pg:v1 name: db volumeMounts: - name: secrets mountPath: "/etc/secrets" readOnly: true ports: - name: cp containerPort: 5432 hostPort: 5432

将Secret导出到环境变量中

       env:
        - name: WORDPRESS_DB_USER
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: username
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: password

 

ConfigMap  容器应用的配置管理

ConfigMap能够经过多种方式在Pod中使用，好比设置环境变量、设置容器命令行参数、在Volume中建立配置文件等。

建立一个配置文件  并将配置引入pod

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-appvars
data:
  key-serverxml:
    <?xml Version='1.0'encoding='utf-8'?>
    <Server port="8005"shutdown="SHUTDOWN">
    .....
      </service>
    </Server>
  key-loggingproperties:
    "handlers=lcatalina.org.apache.juli.FileHandler,
    ...."

    volumeMounts:
    - name: serverxml                          #引用volume名
      mountPath:/configfiles                       #挂载到容器内部目录
        configMap:
          name: cm-test-appconfigfile                  #使用configmap定义的的cm-appconfigfile
          items:
          - key: key-serverxml                     #将key=key-serverxml
            path: server.xml                           #value将server.xml文件名进行挂载
          - key: key-loggingproperties                 #将key=key-loggingproperties    
            path: logging.properties                   #value将logging.properties文件名进行挂载　

健康检查的三种方式

ExecAction：在容器内部执行一个命令，若是该命令的返回值为0，则表示容器健康

TCPSocketAction：经过容器ip地址和端口号执行TCP检查，若是可以创建tcp链接代表容器健康

HTTPGetAction：经过容器Ip地址、端口号及路径调用http get方法请求资源，若是响应的状态吗大于200且小于400，则认为容器健康

spec:
  containers:
  - name: tomcat
    image: grc.io/google_containers/tomcat
    args:  配置一个命令，健康检查执行
    -/bin/sh
    - -c
    -echo ok >/tmp.health;sleep10; rm -fr /tmp/health;sleep600
    livenessProbe:
      exec:
        command:
        -cat
        -/tmp/health
      initianDelaySeconds:15
      timeoutSeconds:1　
  
  livenessProbe:
      tcpSocket:
        port: 80
      initianDelaySeconds:30
      timeoutSeconds:1

    livenessProbe:
      httpGet:
        path:/_status/healthz
        port: 80
      initianDelaySeconds:30
      timeoutSeconds:1

initialDelaySeconds：启动容器后首次监控检查的等待时间，单位秒
timeouSeconds：健康检查发送请求后等待响应的超时时间，单位秒。当发生超时就被认为容器没法提供服务无，该容器将被重启

健康检查

NodeSelector:定向调度

给node打上标签 kubectl label nodes k8s-node-1 label1=test

nodeSelector:
          label1: test

 

NodeAffinity：亲和性调度

该调度策略是未来替换NodeSelector的新一代调度策略。因为NodeSelector经过Node的Label进行精确匹配，全部NodeAffinity增长了In、NotIn、Exists、DoesNotexist、Gt、Lt等操做符来选择Node。调度侧露更加灵活。

• 日志收集，好比fluentd，logstash等
• 系统监控，好比Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond等
• 系统程序，好比kube-proxy, kube-dns, glusterd, ceph等

kubectl get namespaces
kubectl create namespace new-namespace
kubectl get pods -l label名 -n namespace名
kubectl scale deployment nginx-deployment --replicas 10 扩容
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 更新镜像部署
kubectl edit deployment/nginx-deployment
kubectl create -f deployment.yaml文件 -n 命名空间
kubectl delete pods pods名称
kubectl get svc -n 名称 -o 样式 | 附加范围
kubectl delete pods,services -l name=myLabel(标签) --include-uninitialized(包含还没有初始化的)
kubectl exec -it pod名 /bin/bash -n 命名空间
kubectl rollout history deployment/deployment名称 -n --revision=版本号 查看提交历史
kubectl rollout history deployment/deployment名称 -n
kubectl rollout undo deployment/deployment名称 --to-revision=版本号 -n

kubectl rolling-update redis-master --image=redis-master:2.0  升级内部镜像

kubectl get pods --show-labels kubectl rollout status deployment/nginx-deployment 监控回撤状态 kubectl describe deployment 部署名 -n 空间 查看详细 kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi kubectl get deployment pod名 -o yaml -n 查看部署文件 建立环境变量 将常量参数写入其中 kubectl create configmap env-config --from-literal=log_level=INFO kubectl logs volume-pod -c busybox