本文主要介绍 crd controller 的基本开发过程，让每一个刚接触k8s开发的同学都可以轻松开发自己的控制器。 kubebuilder 简介 kubebuilder 是一个帮助开发者快速开发 kubernetes API 的脚手架命令行工具，其依赖 controller-tools 和 controller-runtime 两个库。其中 controller-runtime 简化 kubernetes controller 的开发，并且对 kubernetes 的几个常用库进行了二次封装， 以简化开发工程。而 controller-tool 主要功能是代码生成。 下图是使用 kubebuilder 的工作流程图： 安装 kubebuilder # download kubebuilder and install locally. ➜ curl -L -o kubebuilder "https://go.kubebuilder.io/dl/latest/$(go env GOOS)/$(go env GOARCH)" ➜ chmod +x kubebuilder && mv kubebuilder /usr/local/bin/ 确认安装成功 ➜ kubebuilder version Version: main.version{KubeBuilderVersion:"3.11.1", KubernetesVendor:"1.27.1", GitCommit:"1dc8ed95f7cc55fef3151f749d3d541bec3423c9", BuildDate:"2023-07-03T13:10:56Z", GoOs:"darwin", GoArch:"amd64"} 相关命令 ➜ kubebuilder --help CLI tool for building Kubernetes extensions and tools.

k8s: v1.27.3 什么是准入控制插件？ 准入控制器 是一段代码，它会在请求通过认证和鉴权之后、对象被持久化之前拦截到达 API 服务器的请求。 准入控制器可以执行 变更（Mutating） 和或 验证（Validating） 操作。 变更（mutating）控制器可以根据被其接受的请求更改相关对象；验证（validating）控制器则不行。 准入控制器限制创建、删除、修改对象的请求。 准入控制器也可以阻止自定义动作，例如通过 API 服务器代理连接到 Pod 的请求。 准入控制器不会 （也不能）阻止读取（get、watch 或 list）对象的请求。 某些控制器既是变更准入控制器又是验证准入控制器。如果两个阶段之一的任何一个控制器拒绝了某请求，则整个请求将立即被拒绝，并向最终用户返回错误。 Kubernetes 1.27 中的准入控制器由下面的列表组成， 并编译进 kube-apiserver 可执行文件，并且只能由集群管理员配置。 在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。 它们根据 API 中的配置， 分别执行变更和验证准入控制 webhook。 参考： https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/ 同类型的webhook的顺序无关紧要。 什么是准入 Webhook？ 除了内置的 admission 插件， 准入插件可以作为扩展独立开发，并以运行时所配置的 Webhook 的形式运行。 此页面描述了如何构建、配置、使用和监视准入 Webhook。 准入 Webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。 可以定义两种类型的准入 webhook，即 修改性质的准入 Webhook(Mutating admission) 和 验证性质的准入 Webhook ( Validating admission) 。 Mutalting Webhook 会先被调用，它们可以更改发送到 API 服务器的对象以执行自定义的设置默认值操作。

Kubernetes 控制器管理器（kube-controller-manager）是一个守护进程，内嵌随 Kubernetes 一起发布的核心控制回路。 在机器人和自动化的应用中，控制回路是一个永不休止的循环，用于调节系统状态。 在 Kubernetes 中，每个控制器是一个控制回路，通过 API 服务器监视集群的共享状态， 并尝试进行更改以将当前状态转为期望状态。 目前，Kubernetes 自带的控制器例子包括副本控制器、节点控制器、命名空间控制器和服务账号控制器等。 本文不对 kube-controller-manager 管理的每个控制器的执行原理做介绍，只是从全局观看一下kube-controller-manager 启动每个控制器的整体实现过程。 k8s: v1.27.3 文件： cmd/kube-controller-manager/app/controllermanager.go 控制器选项初始化 // cmd/kube-controller-manager/app/controllermanager.go#L104 func NewControllerManagerCommand() *cobra.Command { // 所有内置控制器配置 s, err := options.NewKubeControllerManagerOptions() } 调用 options.NewKubeControllerManagerOptions() 对所有内置控制器及全局配置进行初始化。 func NewKubeControllerManagerOptions() (*KubeControllerManagerOptions, error) { componentConfig, err := NewDefaultComponentConfig() if err != nil { return nil, err } s := KubeControllerManagerOptions{ Generic: cmoptions.NewGenericControllerManagerConfigurationOptions(&componentConfig.Generic), KubeCloudShared: cpoptions.NewKubeCloudSharedOptions(&componentConfig.KubeCloudShared), ServiceController: &cpoptions.ServiceControllerOptions{ ServiceControllerConfiguration: &componentConfig.ServiceController, }, AttachDetachController: &AttachDetachControllerOptions{ &componentConfig.

上一篇 《k8s调度器 kube-scheduler 源码解析》 大概介绍一调度器的内容，提到扩展点的插件这个概念，下面我们看看如何开发一个自定义调度器。 本文源码托管在 https://github.com/cfanbo/sample-scheduler。 插件机制 在Kubernetes调度器中，共有两种插件机制，分别为 in-tree 和 out-of-tree。 In-tree插件（内建插件）：这些插件是作为Kubernetes核心组件的一部分直接编译和交付的。它们与Kubernetes的源代码一起维护，并与Kubernetes版本保持同步。这些插件以静态库形式打包到kube-scheduler二进制文件中，因此在使用时不需要单独安装和配置。一些常见的in-tree插件包括默认的调度算法、Packed Scheduling等。 Out-of-tree插件（外部插件）：这些插件是作为独立项目开发和维护的，它们与Kubernetes核心代码分开，并且可以单独部署和更新。本质上，out-of-tree插件是基于Kubernetes的调度器扩展点进行开发的。这些插件以独立的二进制文件形式存在，并通过自定义的方式与kube-scheduler进行集成。为了使用out-of-tree插件，您需要单独安装和配置它们，并在kube-scheduler的配置中指定它们。 可以看到 in-tree 插件与Kubernetes的核心代码一起进行维护和发展，而 out-of-tree插件可以单独开发并out-of-tree插件以独立的二进制文件部署。因此 out-of-tree插件具有更大的灵活性，可以根据需求进行自定义和扩展，而 in-tree 插件受限于Kubernetes核心代码的功能和限制。 对于版本升级in-tree插件与Kubernetes版本保持同步，而out-of-tree插件可以单独进行版本升级或兼容。 总的来说，in-tree 插件是Kubernetes的一部分，可以直接使用和部署，而 out-of-tree 插件则提供了更多的灵活性和定制化能力，但需要单独安装和配置。 一般开发都是采用out-of-tree 这各机制。 扩展点 参考官方文档 https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework/#%E6%89%A9%E5%B1%95%E7%82%B9 下图显示了一个 Pod 的调度上下文以及调度框架公开的扩展点。 一个插件可以在多个扩展点处注册执行，以执行更复杂或有状态的任务。 对于每个扩展点的介绍，可参考上面给出的官方文档，这里不再做介绍。 我们下面开发的是一个 Pod Scheduling Context 部分的 Filter调度器插件，插件的功能非常的简单，就是检查一个 Node 节点是否存在 cpu=true标签，如果存在此标签则可以节点有效，否则节点视为无效，不参与Pod调度。 插件实现 要实现一个调度器插件必须满足两个条件： 必须实现对应扩展点插件接口 将此插件在调度框架中进行注册。 不同扩展点可以启用不同的插件。 插件实现 每个扩展点的插件都必须要实现其相应的接口，所有的接口定义在 https://github.com/kubernetes/kubernetes/blob/v1.27.3/pkg/scheduler/framework/interface.go。 // Plugin is the parent type for all the scheduling framework plugins. type Plugin interface { Name() string } // FilterPlugin is an interface for Filter plugins.

上一节《GoLand+dlv进行远程调试》我们介绍了如何使用 GoLand 进行远程调试，本节我们就以 kube-apiserver 为例演示一下调试方法。 服务器环境 作为开发调试服务器，需要安装以下环境 安装 Golang 环境，国内最好设置 GOPROXY 安装 dlv 调试工具 安装 Docker 环境， 同时安装 containerd 服务（对应官方教程中的 containerd.io 安装包）并设置代理 同步代码(本地) 以下为我们本机环境设置。 本机下载 kubernetes 仓库 git clone --filter=blob:none https://github.com/kubernetes/kubernetes.git 这里指定 –filter=bold:none 可以实现最小化下载 这里 k8s 项目目录为 /Users/sxf/workspace/kubernetes, 对应远程服务器目录为 /home/sxf/workspace/kubernetes，如图所示 映射关系配置 同时选择自动上传 Automatic upload (Always) 菜单，这样以后当本地文件有变更时将自动同步到远程服务器。 首次手动同步远程代码(右键Upload here菜单) 如果文件特别多的话，首次同步将会比较慢，可以手动将本地项目打包上传到远程服务器再解压。 环境检测 首先对当前调试环境进行一系列的检查，如果条件不满足将给出提示信息 $ make verify 如果本地 Git 仓库存在未提交的文件的话，则此时将提示先提交。这一块有点不好，我这里直接终止了这个检查继续下一步。 安装Etcd 由于 kube-apiserver 依赖于 ectd ，所以必须先安装etcd。 $ cd workspace/kubernetes $ ./hack/install-etcd.sh Downloading https://github.com/coreos/etcd/releases/download/v3.5.7/etcd-v3.5.7-linux-amd64.tar.gz succeed etcd v3.

上一篇《Kubelet 服务引导流程》我们讲了kubelet的大概引导流程, 本节我们看一下 Plugins 这一块的实现源码。 version: v1.27.3 插件模块入口 入口文件 /pkg/kubelet/kubelet.go中的 NewMainKubelet() 函数， func NewMainKubelet(kubeCfg *kubeletconfiginternal.KubeletConfiguration,...) (*Kubelet, error) { ... // 插件管理器 /pkg/kubelet/kubelet.go#L811-L814 klet.pluginManager = pluginmanager.NewPluginManager( klet.getPluginsRegistrationDir(), /* sockDir */ kubeDeps.Recorder, ) ... } 这里第一个参数 klet.getPluginsRegistrationDir() 是返回 plugins 所在目录，默认位于kubelet目录下的 plugins_registry 目录，因此完整的路径为 /var/lib/kubelet/plugins_registry。（这些sock文件是由谁创建的呢？）同时将sock放在子目录里。 const( DefaultKubeletPluginsRegistrationDirName = "plugins_registry" ) func (kl *Kubelet) getPluginsRegistrationDir() string { return filepath.Join(kl.getRootDir(), config.DefaultKubeletPluginsRegistrationDirName) } 第二个参数 kubeDeps.Recorder 是一个事件记录器 EventRecorder ，这里不需要关心。 我们看一下函数 NewPluginManager() 的实现。 // pkg/kubelet/pluginmanager/plugin_manager.go#L54-L80 func NewPluginManager( sockDir string, recorder record.

k8s版本：v1.17.3 组件简介 kube-proxy是Kubernetes中的一个核心组件之一，它提供了一个网络代理和负载均衡服务，用于将用户请求路由到集群中的正确服务。 kube-proxy的主要功能包括以下几个方面： 服务代理：kube-proxy会监听Kubernetes API服务器上的服务和端口，并将请求转发到相应的后端Pod。它通过在节点上创建iptables规则或使用IPVS（IP Virtual Server）进行负载均衡，以保证请求的正确路由。 负载均衡：当多个Pod实例对外提供相同的服务时，kube-proxy可以根据负载均衡算法将请求分发到这些实例之间，以达到负载均衡的目的。它可以基于轮询、随机、源IP哈希等算法进行负载均衡。 故障转移：如果某个Pod实例不可用，kube-proxy会检测到并将其自动从负载均衡轮询中移除，从而保证用户请求不会被转发到不可用的实例上。 会话保持（Session Affinity）：kube-proxy可以通过设置会话粘性（Session Affinity）来将同一客户端的请求转发到同一Pod实例，从而保持会话状态的一致性。 网络代理：kube-proxy还可以实现网络地址转换（NAT）和访问控制列表（ACL）等网络代理功能，通过为集群内的服务提供统一的入口地址和访问策略。 总之 kube-proxy 在Kubernetes集群中扮演着路由和负载均衡的重要角色，为集群内的服务提供可靠的网络连接和请求转发功能。 实现逻辑 组件入口文件为 [cmd/kube-proxy/proxy.go](https://github.com/kubernetes/kubernetes/blob/v1.27.3/cmd/kube-proxy/proxy.go)。 这里我们先介绍一下 options 这个数据结构，它主要有来存储一些配置项 type Options struct { // 配置文件路径 ConfigFile string ​ // 将配置写入到文件 WriteConfigTo string ​ // bool值，如果为true,则删除所有iptables/ipvs 规则，然后退出程序 CleanupAndExit bool // WindowsService should be set to true if kube-proxy is running as a service on Windows. // Its corresponding flag only gets registered in Windows builds WindowsService bool ​ // KubeProxy configuration配置 config *kubeproxyconfig.

版本号：v1.27.2 Kubernetes 调度程序作为一个进程与其他主组件（例如 API 服务器）一起运行。它与 API 服务器的接口是监视具有空 PodSpec.NodeName 的 Pod，并且对于每个 Pod，它都会发布一个 Binding，指示应将 Pod 调度到哪里。 调度过程 +-------+ +---------------+ node 1| | +-------+ | +----> | Apply pred. filters | | | | +-------+ | +----+---------->+node 2 | | | +--+----+ | watch | | | | | +------+ | +---------------------->+node 3| +--+---------------+ | +--+---+ | Pods in apiserver| | | +------------------+ | | | | | | +------------V------v--------+ | Priority function | +-------------+--------------+ | | node 1: p=2 | node 2: p=5 v select max{node priority} = node 2 有关调度算法见： https://github.

Ubuntu 22.04.2 LTS ARM64位系统 kubernetes v1.27.2 以前写过一篇安装教程 https://blog.haohtml.com/archives/30924 ，当时安装的版本是 < v1.24.0 版本，由于k8s 从 v1.24.0 版本开始，弃用了 Dockershim 因此没有办法继续使用 Docker Engine 作为运行时，因此如果还想继续使用旧的运行时的话，则需要安装一个 cri-docker 的软件， 本文主要是介绍（版本 >=v1.24.0 ）继续使用 Docker Engine 的安装方法，这里以最新版本 v1.27.1 为例。 安装环境初始化 以下内容来自： https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/ 执行下述指令： cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF ​ sudo modprobe overlay sudo modprobe br_netfilter ​ # 设置所需的 sysctl 参数，参数在重新启动后保持不变 cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 EOF ​ # 应用 sysctl 参数而不重新启动 sudo sysctl --system 通过运行以下指令确认 br_netfilter 和 overlay 模块被加载：

本方主要介绍有关 client go 架构实现原理，其中一个十分重要的组件就是 informer，它也是我们本文的重点， Informer 机制 采用 k8s HTTP API 可以查询集群中所有的资源对象并 Watch 其变化，但大量的 HTTP 调用会对 API Server 造成较大的负荷，而且网络调用可能存在较大的延迟。除此之外，开发者还需要在程序中处理资源的缓存，HTTP 链接出问题后的重连等。为了解决这些问题并简化 Controller 的开发工作，K8s 在 client go 中提供了一个 informer 客户端库，可以视其为一个组件。 在 Kubernetes 中，Informer 可以用于监视 Kubernetes API 服务器中的资源并将它们的当前状态缓存到本地(index -> store) ，这样就避免了客户端不断地向 API 服务器发送请求，直接从本地即可。 相比直接采用 HTTP Watch，使用 Kubernetes Informer 有以下优势： 减少 API 服务器的负载：通过在本地缓存资源信息，Informer 减少了需要向 API 服务器发出的请求数量。这可以防止由于 API 服务器过载而影响整个集群的性能。 提高应用程序性能：使用缓存的数据，客户端应用程序可以快速访问资源信息，而无需等待 API 服务器响应。这可以提高应用程序性能并减少延迟。 简化代码：Informer 提供了一种更简单、更流畅的方式来监视 Kubernetes 中的资源更改。客户端应用程序可以使用现有的 Informer 库来处理这些任务，而无需编写复杂的代码来管理与 API 服务器的连接并处理更新。 更高的可靠性：由于 Informer 在本地缓存数据，因此即使 API 服务器不可用或存在问题，它们也可以继续工作。这可以确保客户端应用程序即使在底层 Kubernetes 基础结构出现问题时也能保持功能。 下面一起看一下 client-go 库的实现原理

在k8s中的时间会提示证书过期问题，如 # kubectl get nodes Unable to connect to the server: x509: certificate has expired or is not yet valid 这里我们介绍一下续期方法。 注意：当前集群通过 kubeadm 命令创建。 kubeadm 安装得证书默认为 1 年，注意原证书文件必须保留在服务器上才能做延期操作，否则就会重新生成，集群可能无法恢复。 准备 这里先查看一下测试集群的证书过期时间 # kubeadm certs check-expiration [check-expiration] Reading configuration from the cluster... [check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml' CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED admin.conf Aug 30, 2022 03:18 UTC 324d no apiserver Aug 30, 2022 03:18 UTC 324d ca no apiserver-etcd-client Aug 30, 2022 03:18 UTC 324d etcd-ca no apiserver-kubelet-client Aug 30, 2022 03:18 UTC 324d ca no controller-manager.

在使用kubenetes的过程中，如何将服务开放到集群外部访问是一个重要的问题。当使用云平台（阿里云、腾讯云、AWS等）的容器服务时，我们可以通过配置 service 为 LoadBalancer 模式来绑定云平台的负载均衡器，从而实现外网的访问。但是，如果对于自建的 kubernetes裸机集群，这个问题则要麻烦的多。 祼机集群不支持负载均衡的方式，可用的不外乎NodePort、HostNetwork、ExternalIPs等方式来实现外部访问。但这些方式并不完美，他们或多或少都存在的一些缺点，这使得裸机集群成为Kubernetes生态系统中的二等公民。 MetalLB 旨在通过提供与标准网络设备集成的Network LB实施来解决这个痛点，从而使裸机群集上的外部服务也尽可能“正常运行”，减少运维上的管理成本。它是一种纯软件的解决方案，参考 https://kubernetes.github.io/ingress-nginx/deploy/baremetal/。 从 v0.13.0 版本开始，官方对解决方案进行了部分调整，操作步骤简洁一些，建议使用最新版本，参考官方教程 https://metallb.universe.tf/installation/ 部署 创建namespace $ kubectl create namespace metallb-system 新建 secret $ kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)" 参数 from 前面是两个- 部署 root@sxf-virtual-machine:~# kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.12.1/manifests/metallb.yaml Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+ podsecuritypolicy.policy/controller created podsecuritypolicy.policy/speaker created serviceaccount/controller created serviceaccount/speaker created clusterrole.rbac.authorization.k8s.io/metallb-system:controller created clusterrole.rbac.authorization.k8s.io/metallb-system:speaker created role.rbac.authorization.k8s.io/config-watcher created role.rbac.authorization.k8s.io/pod-lister created role.

环境 ubuntu18.04 64位 Kubernetes v1.21.3 这里需要注意，本教程安装的k8s版本号 <- v1.24.0，主要是因为从v1.24.0以后移除了 Dockershim，无法继续使用 Docker Engine，后续将默认采用 containerd ，它是一个从 CNCF 毕业的项目。如果仍想使用原来 Docker Engine 的方式可以安装 cri-dockerd ，它是 Dockershim 的替代品。 如果你想将现在 Docker Engine 的容器更换为 containerd，可以参考官方迁移教程 将节点上的容器运行时从 Docker Engine 改为 containerd 为了解决国内访问一些国外网站慢的问题，本文使用了国内阿里云的镜像。 更换apt包源 这里使用aliyun镜像 , 为了安全起见，建议备份原来系统默认的 /etc/apt/sources.list 文件 编辑文件 /etc/apt/sources.list，将默认网址 或 替换为 更新缓存 $ sudo apt-get clean all $ sudo apt-get update 安装Docker 参考官方文档 或 aliyun 文档 安装 docker 安装基础工具 $ sudo apt update $ sudo apt-get install apt-transport-https ca-certificates curl gnupg lsb-release 安装GPG证书 $ curl -fsSL https://download.

对于一个刚刚接触kubernetes(k8s)的新手来说，想好更好的学习它，首先就要对它有一个大概的认知，所以本文我们先以全局观来介绍一个kubernetes。 kubernetes架构 kubernetes 架构图 kubernets整体可以分为两大部分，分别为 Master 和 Node ，我们一般称其为节点，这两种角色分别对应着控制节点和计算节点，根据我们的经验可以清楚的知道 Master 是控制节点。 Master 节点 控制节点 Master 节点由三部分组成，分别为 Controller Manager 、 API Server 和 Scheduler ，它们相互紧密协作，每个部分负责不同的工作职责。 controller-manager 全称为 kube-controler-manager 组件，主要用来负责容器编排。如一个容器(实际上是pod，pod是最基本的调度单元。一般一个pod里会部署一个容器服务)服务可以指定副本数量，如果实际运行的副本数据与期望的不一致，则会自动再启动几个容器副本，最终实现期望的数量。这个组件，就是一系列控制器的集合。我们可以查看一下 Kubernetes 项目的 pkg/controller 目录, 伪代码如下： for { 实际状态 := 获取集群中对象X的实际状态（Actual State） 期望状态 := 获取集群中对象X的期望状态（Desired State） if 实际状态 == 期望状态{ 什么都不做 } else { 执行编排动作，将实际状态调整为期望状态 } } api server 对外提供api服务，用来接收命令进行集群管理。对内负责与etcd注册中心进行通讯，进行一些配置信息的存储与读取 scheduler 负责调度。如一个容器存放到k8s集群中的哪个node节点最为合适 实际上这三个组件的功能远远多于我们这里描述的。 Node 节点 对于节点node，一般我们可以理解为一台物理机或者vm服务器。同样 node 也是由多个组件组成，其中最为重要的是一个 kubelet 组件。它负责与容器运行时打交道，一般每个node节点都会安装这个组件。 这里有几个关键的概念 CNI Container Networking Interface 负责 kubelet 与 网络(Network) 通讯。 CRI Container Runtime Interface 负责 kubelet 与 运行时(Container Runtime) 通讯。定义了容器运行时的一些关键操作，如启动容器时需要的所有参数。 CSI Container Storage Interface 负责 kubelet 与 存储(Volume Plugin) 通讯， OCI Open Container Initiative 可以看作是一个容器运行时标准。负责 运行时 Runtime 与 操作系统OS 通讯。即把CRI 请求转换成对Linux 操作系统的调用（如 namespace 和 cgroups) 对于CRI 和 OCI 接口的关系变成为下图所示CRI / OCI

集群中的服务要想向外提供服务，就不得不提到Service和Ingress。 下面我们就介绍一下两者的区别和关系。 Service 必须了解的一点是 Service 的访问信息在 Kubernetes 集群内是有效的，集群之外是无效的。 Service可以看作是一组提供相同服务的Pod对外的访问接口。借助Service，应用可以方便地实现服务发现和负载均衡。对于Service 的工作原理请参考 当需要从集群外部访问k8s里的服务的时候，方式有四种：ClusterIP（默认）、NodePort、LoadBalancer、ExternalName 。 下面我们介绍一下这几种方式的区别 一、ClusterIP 该方式是指通过集群的内部 IP 暴露服务，但此服务只能够在集群内部可以访问，这种方式也是默认的 ServiceType。 我们先看一下最简单的Service定义 apiVersion: v1 kind: Service metadata: name: hostnames spec: selector: app: hostnames ports: - name: default protocol: TCP port: 80 targetPort: 9376 这里我使用了 selector 字段来声明这个 Service 只携带了 app=hostnames 标签的 Pod。并且这个 Service 的 80 端口，代理的是 Pod 的 9376 端口。 我们定义一个 Deployment apiVersion: apps/v1 kind: Deployment metadata: name: hostnames spec: selector: matchLabels: app: hostnames replicas: 3 template: metadata: labels: app: hostnames spec: containers: - name: hostnames image: k8s.

本机为mac环境，安装有brew工具，所以为了方便这里直接使用brew来安装minikube工具。同时本机已经安装过VirtualBox虚拟机软件。 minikube是一款专门用来创建k8s 集群的工具。 一、安装minikube 参考 , 在安装minkube之前建议先了解一下minikube需要的环境。 先安装一个虚拟化管理系统，如果还未安装，则在 HyperKit、VirtualBox 或 VMware Fusion 三个中任选一个即可，这里我选择了VirtualBox。 如果你想使用hyperkit的话，可以直接执行 brew install hyperkit 即可。 对于支持的driver_name有效值参考, 目前docker尚处于实现阶段。 $ brew install minikube 查看版本号 $ minikube version minikube version: v1.8.2 commit: eb13446e786c9ef70cb0a9f85a633194e62396a1 安装kubectl命令行工具 $ brew install kubectl 二、启动minikube 创建集群 $ minikube start --driver=virtualbox 如果国内的用户安装时提示失败”VM is unable to access k8s.gcr.io, you may need to configure a proxy or set –image-repository”, 则指定参数_–image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers_ $ minikube start --driver=virtualbox --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers 😄 minikube v1.8.2 on Darwin 10.

目前新版本的 kubernetes dashboard （）安装了后，为了安全起见，默认情况下已经不向外提供服务，只能通过 http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/ 本机访问。在我们学习过程中，总有些不方便，这时我们可以利用 kubectl proxy 命令来实现。 首先我们看一下此命令的一些想着参数 ➜ ~ kubectl proxy -h To proxy all of the kubernetes api and nothing else, use: $ kubectl proxy --api-prefix=/ To proxy only part of the kubernetes api and also some static files: $ kubectl proxy --www=/my/files --www-prefix=/static/ --api-prefix=/api/ The above lets you 'curl localhost:8001/api/v1/pods'. To proxy the entire kubernetes api at a different root, use: $ kubectl proxy --api-prefix=/custom/ The above lets you 'curl localhost:8001/custom/api/v1/pods' Examples: # Run a proxy to kubernetes apiserver on port 8011, serving static content from .

k8s guide 准备 对于一个新手来说，第一步是必须了解什么是 kubernetees、 设计架构 和相关 概念。只有在了解了这些的情况下，才能更好的知道k8s中每个组件的作用以及它解决的问题。 安装工具 minikube 参考 https://minikube.sigs.k8s.io/docs/start/ kind 参考 https://kind.sigs.k8s.io/docs/user/quick-start/ 以上是安装k8s环境的两种推荐方法，这里更推荐使用kind。主要原因是 minikube 只支持单个节点，而 kind 可以支持多个节点，这样就可以实现在一台电脑上部署的环境与生产环境一样，方便大家学习。 要实现管理控制 Kubernetes 集群资源如pod、node、service等的管理，还必须安装一个命令工具 kubectl ，请参考： https://kubernetes.io/zh/docs/tasks/tools/ 学习文档 Kubernetes 文档 https://kubernetes.io/zh/docs/home/ Play with Kubernetes https://labs.play-with-k8s.com/ Kubernetes中文指南/云原生应用架构实践手册 – https://jimmysong.io/kubernetes-handbook