云原生之k8s初介绍

目录

1.云原生

2.kubernetes

2.1 Overview 

2.2 Core Concept

2.2.1 pods

2.2.2 replication Controllers

2.2.3 services

2.2.4 volumes： attaching disk storage to containers

2.2.5 ConfigMaps and Secrets: configuring applications

2.2.6  Access pod metadata and other resources from applicaion

​2.2.7  Deployments:updating applications declaratively

 2.2.8  StatefulSets: deploying replicated stateful applications

---

1.云原生

云原生没有明确的定义，从技术的角度主要包括下面7大部分

微服务：服务和服务之间通过高内聚低耦合的方式交互

容器：作为微服务的承载载体

容器编排：解决微服务在生产环境中的部署问题

服务网格：解决了服务之间的通信

声明式API：让系统更加健壮

        命令式API：可以直接发出服务器执行的命令，如运行容器，停止容器

        声明式API：可以声明期望状态，系统将不断的调整到期望状态

不可变基础设施：方便快速扩展升级新系统

 DevOps：缩短研发周期，增加部署频率和速度

2.kubernetes

容器编排是一个重要的技术，其中kubernetes（k8s）截至发稿日已经成为主导的容器编排技术。

2.1 Overview 

k8s可以方便管理项目，将一个大项目拆成若干小项目，便于管理，而且屏蔽了底层的物理机器，让不是专业的人也可以轻松部署自己的应用，并且支持回滚，重启等多种机智。

k8s集群

 分为control（master）和worker

master node

        K8s API:你和以及其他的控制平台交互

        Scheduler:管理APP的时间表        

        Manager:管理集群功能的，如复制，追踪和处理节点失败

        Etcd:：一个可信的分布式数据库，永久存储集群配置

Worker node:

        Docker：容器

        Kubelet：和API Server交互，管理节点内容器

        Kube-proxy：处理应用之间的网络流量负载平衡

2.2 Core Concept

2.2.1 pods

pod管理container，容器是微服务的载体，然后pod可以管理容器

因为container的设计是通常里面是单线程（有些程序线程里有子线程），所以需要pod组织起多个线程，也就是容器，

通常一个pod里是功能相似或者相互辅佐的容器。为了区分pod，可以打label等

2.2.2 replication Controllers

因为单纯起了一个pod，无法管理，挂掉了也不知道怎么重启，但有replication controllers，pod挂掉后可以重启。这个是管理pod的。

Liveness probes：检查pod是否正常运行，3种方式

        1.Http get

        2.Tcp socket

        3.Exec pod

RC：管理pod，让其run healthy，譬如挂掉重启，相比于pod本身的重启，其可以跨worker node重启部署

但其缺点是只能管理一种label select的pod

RS：replicaSet：可以管理多个label的pod（现在用RS的比较多）

DaemonSet：实现在每个node（or指定的node，通过给node打label来实现区分不同的node）部署一个pod（像抓取log这种通用的每个节点都需要的node）。

特点：关心node（RS，RC不关心）；每个node上只部署一个pod，而不是多个

Job resource：到pod进程结束后，就结束这个pod（RC，RS，DS并不具备这种特性）

 

 

 

 2.2.3 services

services：是客户端和pod间交流通信

 

service的类型有四种:

1. ExternalName: 用于将集群外部的服务引入到集群内部，在集群内部可直接访问来获取服务。

它的值必须是 FQDN, 此FQDN为集群内部的FQDN, 即: ServiceName.Namespace.Domain.LTD.

然后CoreDNS接受到该FQDN后，能解析出一个CNAME记录, 该别名记录为真正互联网上的域名.

如: www.test.com, 接着CoreDNS在向互联网上的根域DNS解析该域名，获得其真实互联网IP.

2. ClusterIP： 用于为集群内Pod访问时,提供的固定访问地址,默认是自动分配地址,可使用ClusterIP关键字指定固定IP.

3. NodePort: 用于为集群外部访问Service后面Pod提供访问接入端口.

这种类型的service工作流程为:

Client----->NodeIP:NodePort----->ClusterIP:ServicePort----->PodIP:ContainerPort

4. LoadBalancer: 用于当K8s运行在一个云环境内时,若该云环境支持LBaaS,则此类型可自动触发创建

一个软件负载均衡器用于对Service做负载均衡调度.

因为外部所有Client都访问一个NodeIP,该节点的压力将会很大, 而LoadBalancer则可解决这个问题。

而且它还直接动态监测后端Node是否被移除或新增了，然后动态更新调度的节点数。

 上图的访问：回复是任意pod，而不是某个确定的pod。sessionaffinity解决这个事情

 

 上图的load balancer的设计主要是为了云

endpoint有点类似于注册表

PS：探针的两种类型

Living probes探测不存在就消灭

Readness probes单纯的探测

DNS返回一个单一IP-cluster IP，但是如果不想返回则会返回全部pods ip

2.2.4 volumes： attaching disk storage to containers

volunmes给容器提供存储的：不是单独于kubernetes的项目，不能自己删除和创建

 2.2.5 ConfigMaps and Secrets: configuring applications

configMap和secrets的作用：解耦配置和容器，这个配置可以用到别的pod上 

不同：secrets存放机密信息，configmap存放普通信息

  2.2.6  Access pod metadata and other resources from applicaion

通过downward API去和pod交互，有两种方式，一种env，一种是挂载volumn

ambassador可以放在pod内负责和API server通信，example，ambassador可以将pod内的http通信，和pod外的https通信连接起来

 

  2.2.7  Deployments:updating applications declaratively

1.通过replicationController控制update，全部删除，全部更新，有短暂间隔

 2.全部替换

3.通过2个controller

deployment（现在的常用方式）,

比controller更高级,之前的方法需要打开终端操作等待，现在的deployment就不用了,而且稍微修改一下模板就可以修改了，之前controller就不行了

 

 

 

 

  2.2.8  StatefulSets: deploying replicated stateful applications

什么叫stateful，存储网络编号都是固定的，如创建pod，其编号是从开始，而stateless是随机生成一个数字作为pod的名字。如果stateful的pod消失，恢复的话pod名字，网络存储均不变