xzpdxz的博客

基于Gitlab构建企业级CICD runner Pipeline

微服务微服务架构，将应用程序构建为独立的组件，并将每个应用程序进程作为一项服务运行这些服务使用轻量级 API 通过明确定义的接口进行通信由于它们是独立运行的，因此可以针对各项服务进行更新、部署和扩展，以满足对应用程序特定功能的需求背景传统的物理部署，运维起来相对繁琐，且环境难以维护单容器部署，难以保证并发性能容器集群化+自动扩容，可以解决上面两个问题，但是最少会有一个容器运行，对资源会有一定浪费容器集群化+自动扩容+微服务，解决了资源成本问题，在我们需要时按需启动容器方案fissi

参考本地安装docker安装dockercurl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun启动dockerservice docker start安装prometheusnamespaces.yamlapiVersion: v1kind: Namespacemetadata: name: monitoringprometheus-dep.yamlapiVersion: apps/v1kind

参考metrics-server修改metrics-server-deployment.yaml中镜像apiVersion: v1kind: ServiceAccountmetadata: name: metrics-server namespace: kube-system---apiVersion: apps/v1kind: Deploymentmetadata: name: metrics-server namespace: kube-system labels:

下载yamlapiVersion: v1kind: Namespacemetadata: name: ingress-nginx labels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx---kind: ConfigMapapiVersion: v1metadata: name: nginx-configuration namespace:

kubectx：用于切换kubernetes context kube-ps1：为命令行终端增加$PROMPT字段 kube-shell：交互式带命令提示的kubectl终端kube-shell开源项目kube-shell可以为kubectl提供自动的命令提示和补全，使用起来特别方便，推荐给大家。Kube-shell有以下特性：命令提示，给出命令的使用说明 自动补全，列出可选命令并可以通过tab键自动补全，支持模糊搜索 高亮 使用tab键可以列出可选的对象 vim模式M...

QoS（Quality of Service），大部分译为“服务质量等级”，又译作“服务质量保证”，是作用在 Pod 上的一个配置，当 Kubernetes 创建一个 Pod 时，它就会给这个 Pod 分配一个 QoS 等级，可以是以下等级之一：Guaranteed：Pod 里的每个容器都必须有内存/CPU 限制和请求，而且值必须相等。 Burstable：Pod 里至少有一个容器有内存或者 CPU 请求且不满足 Guarantee 等级的要求，即内存/CPU 的值设置的不同。 BestEffort

自定义资源是对 Kubernetes API 的扩展，kubernetes 中的每个资源都是一个 API 对象的集合，例如我们在 YAML 文件里定义的那些 spec 都是对 kubernetes 中的资源对象的定义，所有的自定义资源可以跟 kubernetes 中内建的资源一样使用 kubectl 操作。Kubernetes1.6 版本中包含一个内建的资源叫做 TPR（ThirdPartyResource），可以用它来创建自定义资源，但该资源在 kubernetes1.7 中版本已被 CRD（Cust

为了管理存储，Kubernetes提供了Secret用于管理敏感信息，ConfigMap存储配置，Volume、PV、PVC、StorageClass等用来管理存储卷。ConfigMapPod中使用ConfigMap，可以理解为就是一种配置文件apiVersion: v1kind: ConfigMapmetadata: name: special-config namespace: defaultdata: special.how: very special.type:

Kubernetes 中提供了良好的多租户认证管理机制，如 RBAC、ServiceAccount 还有各种 Policy 等。Service Account当您创建 pod 的时候，如果您没有指定一个 service account，系统会自动得在与该pod 相同的 namespace 下为其指派一个defaultservice account。如果您获取刚创建的 pod 的原始 json 或 yaml 信息（例如使用kubectl get pods/podename -o yaml命令），您将.

Ingress服务发现Kubernetes中为了实现服务实例间的负载均衡和不同服务间的服务发现，创造了Serivce对象，同时又为从集群外部访问集群创建了Ingress对象。Serviceservice就是访问一组pod的策略，可以理解为在扩容时，有多个pod，那么访问这些pod时，我们访问service，由service去负载均衡，这样我们也不用关心pod内分配的ip是什么。简单理解就是一种ninx的负载均衡器kind: ServiceapiVersion: v1metadata:

Kubernetes 中内建了很多 controller（控制器），这些相当于一个状态机，用来控制 Pod 的具体状态和行为。DeploymentDeployment 为 Pod 和 ReplicaSet 提供了一个声明式定义（declarative）方法，用来替代以前的 ReplicationController 来方便的管理应用。典型的应用场景包括：定义 Deployment 来创建 Pod 和 ReplicaSet 滚动升级和回滚应用 扩容和缩容 暂停和继续 Deployment比

NodeNode 是 Kubernetes 集群的工作节点，可以是物理机也可以是虚拟机。是与master等级别的机器节点。通常该节点需要维护时使用以下命令kubectl cordon <node> # 禁止 Pod 调度到该节点上。kubectl drain <node> # 驱逐该节点上的所有 Pod。kubectl uncordon <node> # 将该节点添加到 kubernetes 集群中Namespace在一个 Kuber.

生命周期由controler控制并维护，Controller 可以创建和管理多个 Pod，提供副本管理、滚动升级和集群级别的自愈能力，注意pod中多个容器时共享的，相当于容器依附的宿主机叫podinit容器在pod中，可以有多个容器，但是可能你的业务应用镜像，可能需要用到业务相关的其他工具，并且你的业务容器起来之前，需要依托其他应用先起来，可以理解为docker-compose中的dependence，所以init容器是在你的应用容器之前起的。在描述中spec的为initContainer以下

1 理念首先，最重要的是你需要认识到 Kubernetes 利用了 “期望状态” 原则。就是说，你定义了组件的期望状态，而 Kubernetes 要将它们始终调整到这个状态例如，你想让你的 Web 服务器始终运行在 4 个容器中，以达到负载均衡的目的，你的数据库复制到 3 个不同的容器中，以达到冗余的目的。这就是你想要的状态。如果这 7 个容器中的任何一个出现故障，Kubernetes 引擎会检测到这一点，并自动创建出一个新的容器，以确保维持所需的状态Kubernetes 的目标旨在消除编排物理

1 创建一个应用deploymentkubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.42 查看kubectl get deployments说明应用正在启动中这个过程包括了：拉取镜像，启动一个pod运行起来（可以理解为先去拉取镜像，在docker run起来的意思）...

使用kubeadm安装1 拉取相应的组件kubeadm config images pull2 初始化master节点kubeadm init --apiserver-advertise-address $(hostname -i) # 这里会返回如下命令，这个命令给node加入master的 # kubeadm join 192.168.0.8:6443 --token rmfucl.lrzg5i67k1lsvts2 --discovery-token-ca-cert-hash s