pod

在Kubernetes中，几乎所有的概念，包括Master、Node、Pod、Label、Namespace、Volume等都可以看作是一种“资源对象”。 从这个角度上来说， Kubernetes是一个高度自动化的资源控制系统 ， 它通过对比etcd中保存的“资源期望状态”和当前环境的“资源实际状态” ， 以此来实现自动控制和自动纠错的功能。 1.Master Master是Kubernetes集群的控制节点，每个kubernetes集群至少有一个Master节点， 它负责整个集群的控制和管理 ，几乎所有的kubectl的命令都是同时Master节点来执行的。 Master节点也可以参与实际任务的执行，但是并不建议这样做，因为master节点必须保证高可用， 一旦master节点宕机，那么整个集群都会处于停滞状态。生产环境建议使用3台独立的服务器作为Master节点。 Master节点的主要组件包括：APIServer、Controller-Manager、Scheduler，还有kubelet、kubectl、etcd等组件。 这些组件会以进程的形式展开。 　　 APIServer ：整个集群的唯一入口，也是连接etcd的唯一入口，所有对资源对象进行的操作都必须通过这个组件来展开。 　　　　所有组件的操作也必须通过APIServer这个组件来实现。 　　 Controller

通过Portworx云原生存储，在Amazon EKS里运行高可用SQL Server容器 在本文我们将分析，如何使用Amazon Elastic Container Service for Kubernetes (Amazon EKS, https://amazonaws-china.com/eks/)，来在容器中部署Microsoft SQL Server。文中讨论的方式和与原理，也适用于其他需要高可用和持久性、并符合可复用的DevOps方式的有状态应用。例如运行MongoDB、Apache Cassandra、MySQL、或者大数据处理等。 首先能够被支持在容器中运行的是SQL Server 2017版本。我们可以在Linux容器中，使用Kubernetes (https://amazonaws-china.com/kubernetes/)来运行SQL Server生产负载。 Microsoft SQL Server是被广泛使用的数据库。SQL Server提供一系列很不错的功能，也有很不错的开发者社区。但是它需要比较多的运维，也比开源的或者云端的数据库成本要更高。很多为了降低成本的用户会转向开源方案来降低软件授权的成本。另一些用户会迁移工作负载到关系数据库管理系统（RDBMS）服务里，比如Amazon RDS for Microsoft SQL Server或者Amazon

有状态应用编排 StatefulSet 本文将主要分享以下四方面的内容： “有状态”需求 用例解读 操作演示 架构设计 “有状态”需求 课程回顾 我们之前讲到过 Deployment 作为一个应用编排管理工具，它为我们提供了哪些功能？ 如下图所示： 首先它支持定义一组 Pod 的期望数量，Controller 会为我们维持 Pod 的数量在期望的版本以及期望的数量； 第二它支持配置 Pod 发布方式，配置完成后 Controller 会按照我们给出的策略来更新 Pod，同时在更新的过程中，也会保证不可用 Pod 数量在我们定义的范围内； 第三，如果我们在发布的过程中遇到问题，Deployment 也支持一键来回滚。 可以简单地说， Deployment 认为：它管理的所有相同版本的 Pod 都是一模一样的副本。 也就是说，在 Deployment Controller 看来，所有相同版本的 Pod，不管是里面部署的应用还是行为，都是完全相同的。 这样一种能力对于无状态应用是支持满足的，如果我们遇到一些有状态应用呢？ 需求分析 比如下图所示的一些需求： 以上的这些需求都是 Deployment 无法满足的，因此 Kubernetes 社区为我们提供了一个叫 StatefulSet 的资源，用来管理有状态应用。 StatefulSet：主要面向有状态应用管理的控制器

在Kubernetes中，资源对象和信息都存储在Etcd中，但是对于某一个服务的配置该如何管理了？ 当然你可以在镜像打包的时候，将配置文件直接配置打包到镜像里面，这样确实可以达到目的。 但是大部分的容器是在运行之后需要改配置，每次都重新打包确实会是一个不小的工作。 当然可以通过文件映射或者环境变量来改变容器的配置，这是稍微比较不错的做法。 但是如果在大规模集群中，容器的配置管理将是一个非常麻烦的事项。 Kubernetes从1.2开始提供一种统一的应用配置管理方案——ConfigMap。 ConfigMap将应用所需的配置信息与程序进行分离，这样配置信息可以更好的被多次复用。 在Kubernetes中，配置信息会被封装成一个个资源资源对象，这样便于集中管理和使用。 如果你需要修改配置，那么只需要修改ConfigMap的引用对象或者直接修改ConfigMao资源对象的配置就可以了。 1.ConfigMap ConfigMap供容器使用的典型用法如下： （1）生成为容器内的环境变量 （2）以Volume的形式挂载为容器内部的文件或者目录 ConfigMap以一个或多个key:value的形式保存在Kubernetes系统中供应用使用， 既可以用于表示一个变量的值（例如apploglevel=info），也可以用于表示一个一个完整配置文件的内容（server.xml=<?xml>）。 2

一 集群资源分类 k8s 中所有的内容都抽象为资源，资源实例化之后叫做对象。 1.名称空间级别：仅在此名称空间下生效。 ① 工作负载型资源（workload）：Pod，ReplicaSet，Deployment，StatefulSet，DaemonSet，Job，CronJob（ ReplicationController 在 v1.11 版本被废弃 ） ② 服务发现及负载均衡型资源（ServiceDiscovery LoadBalance ）：Service，Ingress... ③ 配置与存储型资源：Volume( 存储卷 )，CSI（容器存储接口，可以扩展各种各样的第三方存储卷） ④ 特殊类型的存储卷：ConfigMap（当配置中来使用的资源那类型），Secret（保存敏感数据），DownwardAPI（把外部环境中的信息输出给容器） 2.集群级别：不管在什么名称空间下定义，在其他的名称空间中都能看的到。 例如：Namespace，Node，Role，ClusterRole，RoleBinding，ClusterRoleBinding 3.元数据型 例如：HPA，PodTemplate，LimitRange 二 常用字段说明 1.必须存在的属性 参数名 字段类型 说明 version String K8S API 的版本，目前基本是v1，可以用 kubectl api

两条指令完成部署 # 创建一个Master节点 $ kubeadm init # 将一个Node节点加入到当前集群中 $ kubeadm join <Master节点的IP和端口> kubeadm 搭建非常简单，核心就这两条语句。具体还有网络、存储等配置我们往下看。 部署 Overview 在所有节点上安装 Docker 和 kubeadm； 部署 Kubernetes Master 部署容器网络插件； 部署 Kubernetes Worker； 部署 Dashboard 可视化插件； 部署容器存储插件 查看安装的相关组件信息 [root@kubernetes ~]# kubeadm version kubeadm version: &version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-07T21:17:50Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"} [root@kubernetes ~]# kubectl version Client

Kuerbernetes 1.11 二进制安装 标签（空格分隔）： k8s 2019年06月13日 本文截选 https://k.i4t.com 更多文章请持续关注https://i4t.com 什么是Kubernetes？ Kubernetes是一个完备的分布式系统支撑平台。Kubernetes具有完备的集群管理能力，包括多层次的安全防护和准入机制/多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复功能、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。同时kubernetes提供了完善的管理工具，这些工具覆盖了包括开发、测试部署、运维监控在内的各个环节；因此kubernetes是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式的完备的分布式系统开发和支撑平台 ###Kubernetes 基础服务简介 在这里我们只是简单的介绍一下Kubernetes基础组件,后面文章会有详细介绍！ </br> </br> </br> ####Kubernetes Service 介绍 Service(服务)是分布式集群架构的核心，一个Server 对象拥有如下关键特征 (1) 拥有一个唯一指定的名字(比如mysql-server) (2) 拥有一个虚拟IP (Cluster IP、Service

原文: https://i4t.com/4424.html 首先我们先简单的分析一下"优雅的停止Pod" 优雅停止(Graceful shutdown)这个说法来自于操作系统，比如我们windows关机系统首先会退出软件然后一步步到达关机，而相对的就是硬终止(Hard shutdown)，简单的理解就是直接拔电源 到了微服务中，网关会把流量分配给每个Pod节点上，比如我们上线更新Pod的时候 如果我们直接将Pod杀死，那这部分流量就无法得到正确处理，会影响部分用户，通常来说网关或者注册中心会将我们的服务保持一个心跳，过了心跳超时之后会自动摘除我们的服务，但是有一个问题就是超时时间可能是30秒也可能是60秒，虽然不会影响我们的系统，但是会产生用户轻微抖动。 如果我们在停止前执行一条命令，通知网关或者注册中心这台主机进行下线，那么注册中心就会标记这台主机已经下线，不进行流量转发，用户就不会有任何影响，这就是优雅停止，将滚动更新影响最小化 Pod Hook Pod Hook是由kubelet发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。我们可以同时为Pod中的所有容器都配置hook 在k8s中，理想的状态是pod优雅释放，并产生新的Pod。但是并不是每一个Pod都会这么顺利 Pod卡死，处理不了优雅退出的命令或者操作 优雅退出的逻辑有BUG

K8S : Helm 部署 ELK 7.6 场景 ​ 在 K8S 上部署有状态应用 ELK，收集日常测试数据的上报（应用拨测的 Heartbeat、调用链追踪的 APM、性能指标 metabeat 等）。本文通过rook提供底层存储，用于安装elk的statefulset，然后部署MetalLB实现本地负载均衡，最后通过ingress-control实现访问kibana。 操作步骤 1.安装rook 2.安装helm 3.安装ES 4.安装kibana 5.安装filebeat 6.安装metalLB 7.安装Ingress-control 8.访问测试 1.安装rook 1.1 安装说明 ​ Rook是专用于Cloud-Native环境的文件、块、对象存储服务。它实现了一个自我管理的、自我扩容的、自我修复的分布式存储服务。Rook支持自动部署、启动、配置、分配（provisioning）、扩容/缩容、升级、迁移、灾难恢复、监控，以及资源管理。为了实现所有这些功能，Rook依赖底层的容器编排平台。 ​ Ceph是一个分布式存储系统，支持文件、块、对象存储，在生产环境中被广泛应用。 ​ 此次安装就是通过rook进行ceph进行部署，简化了ceph的安装管理配置。同时也是为了能够利用本地资源。提供storageclass。 1.2 rook和ceph架构 1.2 安装ceph

Pod Definition: Create pod by definition: kubectl create -f [filename] Display pod definition: kubectl get po [pod name] -o yaml/json Getting log: kubectl logs [pod name] -c [container name] Port forwarding: kubectl port-forward [pod name] [localport]:[pod port] Delete pod: kubectl delete po [pod name] kubectl delete po -l [label name=value] kubectl delete ns deletes all pods in a namespace kubectl delete po --all -n [namespace] Spec/containers/image specify container image to use in pod Spec/containers/port is just for information: Labels: App: which specifies which app, component, or