pod

1.service介绍 　　 Kubernetes Service从逻辑上代表了一组Pod，具体是哪些Pod则是由label来挑选的。Service 有自己的IP。而且这个IP是不变的。客户端只需要访问Service的IP，Kubernetes则负责建立和维护Service与Pod的映射关系。无论后端Pod如何变化，对客户端不会有任何影响，因为Service没有变。 2.创建Service 创建一个deployment apiVersion: extensions/v1beta1 kind: Deployment metadata: name: httpd spec: replicas: 2 template: metadata: labels: run: httpd spec: containers: - name: httpd image: httpd ports: - containerPort: 80 启动 两个Pod ，运行httpd 镜像，label是 run:httpd Service 会用这个label来挑选Pod kubectl apply -f httpd.yml Pod 分配了各自的IP，这是IP只能被Kubernetes Cluster 中的容器和节点访问 创建Service apiVersion: v1 kind: Service metadata:

在虚拟化的一系列解决方案中，数据的持久化都是需要我们非常关心的问题，dokcer是这样，Kubernetes也是这样。不过在Kubernetes中，有一个数据卷的概念。 一、Volume简介 我们经常都会说：容器、Pod都是很短暂的！其含义就是容器和Pod的生命周期都是很短暂的，会被频繁地销毁和创建。容器销毁时，保存在容器内部文件系统中的数据都会被清除。 Volume的生命周期独立于容器，Pod中的容器可能被销毁和重启，但Volume会被保留。 Kubernetes Volume主要解决了以下两个问题： 1）数据持久性： 通常情况下，容器运行起来后，写到其文件系统的文件是暂时性的。当容器崩溃后，kubelet会将这个容器不断的重启，当达到重启的次数后，容器仍然不可用，那么就会将这个容器kill掉，重新生成新的容器。此时，新运行的容器并没有原容器中的数据，因为容器是由镜像创建的； 2）数据共享： 同一个Pod中运行的容器之间，经常会存在共享文件/共享文件夹的需求； 从根本上来说，一个数据卷仅仅是一个可以被Pod访问的目录或文件。这个目录是怎么来的，取决于该数据卷的类型。同一个Pod中的两个容器可以将一个数据卷挂载到不同的目录下。 Volume 提供了对各种 backend 的抽象，容器在使用 Volume 读写数据的时候不需要关心数据到底是存放在本地节点的文件系统中呢还是云硬盘上

环境 CentOS 7.1 (64-bit system) MySQL 5.6.24 CentOS 安装 参考： http://www.waylau.com/centos-7-installation-and-configuration/ 依赖 MySQL 依赖 libaio，所以先要安装 libaio yum search libaio # 检索相关信息 yum install libaio # 安装依赖包 成功安装，提示如下： [root@bogon /] # yum install libaio 已加载插件： fastestmirror Loading mirror speeds from cached hostfile * base : mirrors .yun-idc .com * extras : mirrors .163 .com * updates : mirrors .163 .com 软件包 libaio-0 .3 .109-12 .el7 .x86_64 已安装并且是最新版本 无须任何处理 检查 MySQL 是否已安装 yum list installed | grep mysql 如果有，就先全部卸载，命令如下： yum -y remove mysql-libs .x86_64 若有多个依赖文件则依次卸载。当结果显示为 Complete！即卸载完毕。 下载

一、安全机制说明 Kubernetes 作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。API Server 是集群内部各个组件通信的中介，也是外部控制的入口。所以 Kubernetes 的安全机制基本就是围绕保护 API Server 来设计的。Kubernetes 使用了 认证（Authentication）、鉴权（Authorization）、准入控制（AdmissionControl） 三步来保证API Server的安全 二、认证--Authentication 2.1、认证的方式 1）HTTP Token 认证 通过一个 Token 来识别合法用户 HTTP Token 的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串 - Token 来表达客户的一种方式。Token 是一个很长的很复杂的字符串，每一个 Token 对应一个用户名存储在 API Server 能访问的文件中。当客户端发起 API 调用请求时，需要在 HTTP Header 里放入 Token 2）HTTP Base 认证 通过用户名+密码的方式认证 用户名+密码用 BASE64 算法进行编码后的字符串放在 HTTP Request 中的 HeatherAuthorization 域里发送给服务端，服务端收到后进行编码，获取用户名及密码 3）HTTPS 证书认证 最严格，基于

01_Kubernetes入门 /*--> */ /*--> */ 1.1 Kubernetes 是什么？ 基于容器技术的分布式架构领先方案。 Kubernetes 是一个完备的分布式系统支撑平台，Kubernetes 具备完备的集群管理能力，包括： 多层次的安全防护和准入机制、 多租户应用支撑能力、 透明的服务注册和服务发现机制、 内建的智能负载均衡、 强大的故障发现和自我修复能力、 服务滚动升级和在线扩容能力、 可扩展的资源自动调度机制、 多粒度的资源配额管理能力。 Service 在Kubernetes中，Service是分布式集群架构的核心，一个Service对象拥有如下关键特征： 拥有唯一指定的名称（比如mysql-server）。 拥有一个虚拟IP（Cluster IP、ServiceIP或VIP）和端口号。 能够提供某种远程服务能力。 被映射到提供这种服务能力的一组容器应用上。 Service的服务进程目前都是基于Socket通信方式对外提供服务，比如Redis、Memcache、MySQL、Web Server，或者是实现了某个具体业务的特定TCP Server进程。 虽然一个Service通常由多个相关的服务进程提供服务，每个服务进程都有一个独立的Endponit（IP + Port）访问点，但Kubernetes能够让我们通过Service

在现网情况下,业务升级常常需要停机,下面我们使用Deployment来进行不停机升级和回滚. 1.先使用创建多个nginx的pod [ root@node-1 pod ] # cat nginx_deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80 [ root@node-1 pod ] # [ root@node-1 pod ] # kubectl create -f nginx_deployment.yaml [ root@node-1 pod ] # kubectl get pod NAME READY STATUS RESTARTS AGE nginx-deployment-54f57cf6bf-lh2rv 1/1 Running 0 74s nginx-deployment-54f57cf6bf-psbqx 1/1

1、docker不是容器，而是创建容器的工具； 容器和虚拟机 镜像、仓库、容器 2、k8s 一个K8S系统，通常称为一个 K8S集群（Cluster） 。 这个集群主要包括两个部分： 一个Master节点（主节点） 一群Node节点（计算节点） 一看就明白：Master节点主要还是负责管理和控制。Node节点是工作负载节点，里面是具体的容器。 深入来看这两种节点。 首先是 Master节点。 Master节点包括API Server、Scheduler、Controller manager、etcd。 API Server是整个系统的对外接口，供客户端和其它组件调用，相当于“营业厅”。 Scheduler负责对集群内部的资源进行调度，相当于“调度室”。 Controller manager负责管理控制器，相当于“大总管”。 然后是 Node节点 。 Node节点包括Docker、kubelet、kube-proxy、Fluentd、kube-dns（可选），还有就是 Pod 。 Pod是Kubernetes最基本的操作单元。一个Pod代表着集群中运行的一个进程，它内部封装了一个或多个紧密相关的容器。除了Pod之外，K8S还有一个Service的概念，一个Service可以看作一组提供相同服务的Pod的对外访问接口。 Kubelet，主要负责监视指派到它所在Node上的Pod

一、介绍 1、曾经 原先版本是用heapster来收集资源指标才能看，但是现在heapster废弃了。从k8s v1.8开始后，引入了新的功能，即把资源指标引入api； 在使用heapster时，获取资源指标是由heapster自已获取的，heapster有自已的获取路径，没有通过apiserver，后来k8s引入了资源指标API(Metrics API)，于是资源指标的数据就从k8s的api中的直接获取，不必再通过其它途径。 k8s中很多组件是依赖于资源指标API的功能 ，比如kubectl top 、hpa，如果没有一个资源指标API接口，这些组件是没法运行的；Heapster只能根据CPU来进行HPA。 2、目前 metrics-server：它也是一种API Server，提供了核心的Metrics API，就像k8s组件kube-apiserver提供了很多API群组一样，但它不是k8s组成部分，而是托管运行在k8s之上的Pod。metrics-server是一个服务于资源指标的api server，收集cpu利用率、内存利用率等。 为了让用户无缝的使用metrics-server当中的API，还需要把这类自定义的API，通过聚合器（kube-aggregator）聚合到核心API组里，然后可以把此API当作是核心API的一部分，通过kubectl api

官网链接 https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment/ kubernetes提供的控制器列表 ReplicaSet 确保任何时间都有指定的数量Pod副本在运行（Deployment已经包含该功能）。 ReplicationController 确保任何时候都有特定的Pod副本处于运行状态（Deployment已经包含该功能）。 Deployment 是kubernetes最常用的控制器，主要是用于部署无状态应用；我们平时开发的web、webapi、微服务都是无状态应用； StatefulSet 主要是用于部署有状态应用；比如redis、mysql等。 DaemonSet 确保全部或某些节点上运行一个Pod副本。当有节点加入集群时，也会为他们新增一个Pod。当节点从集群中移除时候，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod.主要用于运行存储插件、监控插件、日志插件等。 TTL控制器 现在只支持job,主要用来限制已经完成执行的资源对象的生命周期。 Jobs-Run to Completion 主要用于三种任务类型：非并行作业、固定完成计数的并行作业、具有工作队列的并行作业。 CronJob 根据设定的时间表运行作业。 Deployment 介绍 官网链接

CocoaPods是什么？ 当你开发iOS应用时，会经常使用到很多第三方开源类库，比如JSONKit，AFNetWorking等等。可能某个类库又用到其他类库，所以要使用它，必须得另外下载其他类库，周而复始，可见手动一个个去下载所需类库十分麻烦。另外一种常见情况是，你项目中用到的类库有更新，你必须得重新下载新版本，重新加入到项目中，十分麻烦。然而CocoaPods能解决这些恼人的问题。 CocoaPods应该是iOS最常用最有名的类库管理工具了，上述两个烦人的问题，通过cocoaPods，只需要一行命令就可以完全解决，当然前提是你必须正确设置它。重要的是，绝大部分有名的开源类库，都支持CocoaPods。所以，作为iOS程序员的我们，掌握CocoaPods的使用是必不可少的基本技能了。 如何下载和安装CocoaPods？ 在安装CocoaPods之前，首先要在本地安装好Ruby环境。至于如何在Mac中安装好Ruby环境，请google一下，本文不再涉及。 假如你在本地已经安装好Ruby环境，那么下载和安装CocoaPods将十分简单，只需要一行命令。在Terminator（也就是终端）中输入以下命令： sudo gem install cocoapods 但是，且慢。如果你在天朝，在终端中敲入这个命令之后，会发现半天没有任何反应。原因无他，因为那堵墙阻挡了cocoapods.org