pod

kubernetes 的volume 配置 标签（空格分隔）：kubernetes系列 一：kuberentes 的volume 配置 一：kuberentes 的volume 配置 1.1 背景 说明： 容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。首先，当容器崩溃 时，kubelet 会重启它，但是容器中的文件将丢失——容器以干净的状态（镜像最初的状态）重新启动。其次，在 Pod 中同时运行多个容器时，这些容器之间通常需要共享文件。Kubernetes 中的 Volume 抽象就很好的解决了 这些问题 Kubernetes 中的卷有明确的寿命 —— 与封装它的 Pod 相同。所f以，卷的生命比 Pod 中的所有容器都长，当这 个容器重启时数据仍然得以保存。当然，当 Pod 不再存在时，卷也将不复存在。也许更重要的是，Kubernetes 支持多种类型的卷，Pod 可以同时使用任意数量的卷 1.2 卷的类型 Kubernetes 支持以下类型的卷： 1. awsElasticBlockStore azureDisk azureFile cephfs csi downwardAPI emptyDir 2. fc flocker gcePersistentDisk gitRepo glusterfs hostPath iscsi local nfs

目录 资源对象 创建资源的方法 清单帮助命令 创建测试清单 资源的三种创建方式 资源对象 workload：Pod， ReplicaSet， Deployment， StatefulSet， DaemonSet， Job， Cronjob 服务发现及均衡：Service， Ingress 配置与存储：Volume，CSI，ConfigMap，Secret，DownwardAPI 集群级资源：Namespace，Node，Role，ClusterRole，RoleBinding，ClusterRoleBinding 元数据型资源：HPA，PodTemplate，LimitRange 创建资源的方法 apiserver：仅接受JSON格式的资源定义； 使用yaml格式提供配置清单，apiserver可自动将其转为JSON格式，而后再进行执行； 大部分资源的配置清单: apiVersion: group/version $ kubectl api-versions kind 资源类别（pod,service,deployment等） metadata: 元数据 name 同一个namespace下name必须是唯一的 namespace 命名空间 labels 标签，每一种资源都可以有标签 annotations 资源注解 3.spec: 用户期望的目标状态，disired state

在容器中管理数据主要有两种方式： 1、数据卷（Data Volumes） 2、挂载主机目录 (Bind mounts) 数据卷 数据卷是一个 可供一个或多个容器使用的特殊目录 ，它绕过UFS，可以提供很多有用的特性： 数据卷 可以在容器之间共享和重用 对 数据卷 的修改会立马生效 对 数据卷 的更新，不会影响镜像 数据卷 默认会一直存在，即使容器被删除 注意：数据卷 的使用，类似于 Linux 下对目录或文件进行 mount，镜像中的被指定为挂载点的目录中的文件会隐藏掉，能显示看的是挂载的 数据卷。 选择 -v 还是 -–mount 参数： Docker 新用户应该选择--mount参数，经验丰富的 Docker 使用者对-v或者 --volume已经很熟悉了，但是推荐使用--mount参数。 演示思路： 1、创建一个mysql2 pod，创建一个数据库 2、删除mysql2 pod 3、创建mysql3 pod，指定mysql2的数据卷，查看之前mysql2的数据库是否还存在 通过docker run创建一个mysql2的容器 docker run -d --name mysql2 -p 3303:3306 -e MYSQL_ALLOW_EMPTY_PASSWORD=true mysql:5.7 通过上图可以看到进入pod以后创建一个数据库uu。

Kubernetes Service 本文将主要分享以下四方面的内容： 为什么需要 K8s service； K8s service 用例解读； K8s service 操作演示； K8s service 架构设计。 需求来源 为什么需要服务发现 在 K8s 集群里面会通过 pod 去部署应用，与传统的应用部署不同，传统应用部署在给定的机器上面去部署，我们知道怎么去调用别的机器的 IP 地址。但是在 K8s 集群里面应用是通过 pod 去部署的， 而 pod 生命周期是短暂的。在 pod 的生命周期过程中，比如它创建或销毁，它的 IP 地址都会发生变化，这样就不能使用传统的部署方式，不能指定 IP 去访问指定的应用。 另外在 K8s 的应用部署里，之前虽然学习了 deployment 的应用部署模式，但还是需要创建一个 pod 组，然后这些 pod 组需要提供一个统一的访问入口，以及怎么去控制流量负载均衡到这个组里面。比如说测试环境、预发环境和线上环境，其实在部署的过程中需要保持同样的一个部署模板以及访问方式。因为这样就可以用同一套应用的模板在不同的环境中直接发布。 Service：Kubernetes 中的服务返现与负载均衡 最后应用服务需要暴露到外部去访问，需要提供给外部的用户去调用的。我们上节了解到 pod 的网络跟机器不是同一个段的网络，那怎么让 pod

确保有默认的StorageClass（NFS），以及部署过Prometheus-operator（0.33）和helm（2.13.x） 570 2019-12-03 09:34:14 cd /usr/local/src/ 571 2019-12-03 09:34:14 ll 572 2019-12-03 09:34:17 cd /opt/k8s/ 573 2019-12-03 09:34:18 ll 574 2019-12-03 09:34:39 git clone https://github.com/pravega/zookeeper-operator 575 2019-12-03 09:34:49 yum install git -y 576 2019-12-03 09:35:08 git clone https://github.com/pravega/zookeeper-operator 577 2019-12-03 09:35:44 cd zookeeper-operator/ 578 2019-12-03 09:35:45 ll 579 2019-12-03 09:35:46 cd deploy/ 580 2019-12-03 09:35:47 ll 581 2019-12-03 09:35:49 cd crds/ 582 2019-12-03 09:35:50 ll

1.kubernetes架构与组件 Kubernetes集群是由一组节点，也就是node节点组成，可以是物理服务器，也可以是虚拟机。 每个node节点上都安装了kubelet和kube-proxy这两个node组件。 而安装了master组件的节点称为master node。 node组件通过kubelet组件与master组件进行交互，维护着该node上的pod的生命周期。 一个典型的master集群是由一个master node和若干个承载工作负荷的node组成。 kubernetes通过etcd存储着集群中的所有对象和状态。 kubernetes还提供了集群维护的超级命令行工具kubectl。 （1）master master组件主要包括：Apiserver、Scheduler、Controller Manager和etcd。 Api Server是master组件的中枢，其余的master组件都是通过调用Api的接口，实现各自的功能。 API server是整个集群控制的前端，是唯一可以修改集群状态和数据库的组件。 master组件是Kubernetes集群的大脑。 所有集群的控制命令都传递给Master组件并在其上执行。 每个Kubernetes集群至少有一套Master组件。来负责控制和管理整个集群，才能保证集群的正常运转。 它协调集群中的所有活动，包括集群中应用的调度

apiVersion: v1 #指定api版本，此值必须在kubectl apiversion中 kind: Pod #指定创建资源的角色/类型 metadata: #资源的元数据/属性 name: test-pod #资源的名字，在同一个namespace中必须唯一 labels: #设定资源的标签 k8s-app: apache version: v1 kubernetes.io/cluster-service: "true" annotations: #自定义注解列表 - name: String #自定义注解名字 spec: #specification of the resource content 指定该资源的内容 restartPolicy: Always #表明该容器一直运行，默认k8s的策略，在此容器退出后，会立即创建一个相同的容器 nodeSelector: #节点选择，先给主机打标签kubectl label nodes kube-node1 zone=node1 zone: node1 containers: - name: test-pod #容器的名字 image: 10.192.21.18:5000/test/chat:latest #容器使用的镜像地址 imagePullPolicy: Never #三个选择Always、Never

Kubernetes 核心概念 本文整理自 CNCF 和阿里巴巴联合举办的云原生技术公开课的课时 3：Kubernetes 核心概念。本次课程中，阿里巴巴资深技术专家、CNCF 9个 TCO 之一 李响为大家介绍了 Kubernetes 的主要功能与能力、Kubernetes 的架构以及其核心概念与核心 API 等，精彩不容错过。 本次课程的分享主要围绕以下 3 个部分： 什么是 Kubernetes ：介绍 Kubernetes 的主要功能以及能力； Kubernetes 的架构：介绍 Kubernetes 的核心组件，以及介绍它们之间是如何相互互动连接； Kubernetes 的核心概念与核心 API； 一、什么是 Kubernetes Kubernetes，从官方网站上可以看到，它是一个工业级的容器编排平台。Kubernetes 这个单词是希腊语，它的中文翻译是“舵手”或者“飞行员”。在一些常见的资料中也会看到“ks”这个词，也就是“k8s”，它是通过将8个字母“ubernete ”替换为“8”而导致的一个缩写。 Kubernetes 为什么要用“舵手”来命名呢？大家可以看一下这张图： 这是一艘载着一堆集装箱的轮船，轮船在大海上运着集装箱奔波，把集装箱送到它们该去的地方。我们之前其实介绍过一个概念叫做 container，container 这个英文单词也有另外的一个意思就是

一、创建方式分类： 命令 vs 配置文件 Kubernetes 支持两种方式创建资源： 1.用 kubectl 命令直接创建，比如: kubectl run httpd-app --image= reg.yunwei.edu/learn/httpd:latest --replicas=2 在命令行中通过参数指定资源的属性。 2. 通过配置文件和 kubectl apply 创建，要完成前面同样的工作，可执行命令： kubectl apply -f httpd.yml httpd.yml 的内容为： 下面对这两种方式进行比较。 基于命令的方式： 简单直观快捷，上手快。 适合临时测试或实验。 基于配置文件的方式： 配置文件描述了 What ，即应用最终要达到的状态。 配置文件提供了创建资源的模板，能够重复部署。 可以像管理代码一样管理部署。 适合正式的、跨环境的、规模化部署。 这种方式要求熟悉配置文件的语法，有一定难度。 kubectl apply 不但能够创建 Kubernetes 资源，也能对资源进行更新，非常方便。不过 Kubernets 还提供了几个类似的命令，例如 kubectl create 、 kubectl replace 、 kubectl edit 和 kubectl patch 。 为避免造成不必要的困扰，我们会尽量只使用 kubectl apply,

CRD GitHub地址： https://github.com/kubernetes-sigs/kubebuilder Kubernetes 里资源类型有如下所示： 上述资源类型可以满足大多数分布式系统部署的需求 但是在不同应用业务环境下，对于平台可能有一些特殊的需求，这些需求可以抽象为 Kubernetes 的扩展资源，而 Kubernetes 的 CRD (CustomResourceDefinition)为这样的需求提供了轻量级的机制，保证新的资源的快速注册和使用。 举个栗子： 我希望在 kubernetes 中有 KafkaSource 这个资源， 资源示例 kafka-source.yaml如下： 我们希望在执行 kubectl create -f kafka-source.yaml 之后，在 kubernetes 里会启动一个 pod，这个 pod 会做下面的事情： 它会从地址是 my-cluster-kafka-bootstrap.kafka:9092，topic 是 knative- demo-topic 的 kafka 机群里读取消 将读到的消息，发送到 kubernetes 的一个 Service 去执行 Kuberentes 里并没有 KafkaSource 这个资源可以使用，所以直接执行 kubectl create -f kafka-source