Kube Admission

17 十二月 2018 发布在 CNCF, Kubernetes

External Admission Webhooks 作用及使用场景当需要对某些api请求或者所有请求进行校验或者修改object的时候，可以考虑使用ValidatingAdmissionWebhook或者MutatingAdmissionWebhook，两者的区别： ValidatingAdmissionWebhook不允许在webhook中对Object进行修改，只是返回结果是true或false MutatingAdmissionWebhook运行在webhook中对Object进行修改启用在1.10之前的版本，需要使用 --admission-control 启用相关配置，并且是按配置的顺序来决定运行顺序，因此需要用户对于Admission Controllers 完全了解。在1.10之后的版本，上述配置已经废弃，建议使用--enable-admission-plugins=MutatingAdmissionWebhook,ValidatingAdmissionWebhook，并且用户指定的顺序并不会影响实际运行顺序，更加友好。官方的Using Admission Controllers - Kubernetes有关于这方面的详细说明。流程 kube-apiserver –> 认证鉴权 –> Admission Controller –> webhook 使用创建admission服务，以供kube-apiserver调用 package main import ( "crypto/tls" "encoding/json" "flag" "io/ioutil" "net/http" admissionv1beta1 "k8s.io/api/admission/v1beta1" admissionregistrationv1beta1 "k8s.io/api/admissionregistration/v1beta1" corev1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/serializer" utilruntime "k8s.io/apimachinery/pkg/util/runtime" "k8s.io/klog" ) type patchOperation struct { Op string `json:"op"` Path string `json:"path"` Value interface{} `json:"value,omitempty"` } var scheme = runtime.

作者的图片

Pytimer

Software Develper, Like Go and Cloud

Golang developer

China

在Windows上使用Kubectl连接集群

Jul 7, 2020

平时都在Linux上搭建并操作Kubernetes集群，但是有时候会使用Windows来进行开发或者日常工作，这个时候如果在登录某台Linux主机，通过kubectl命令行操作集群就显得不是很方便，Kubernetes本身也是提供了Windows的命令行，因此在Windows上安装并配置kubectl，用于操作远端的Kubernetes集群。下面就是相关步骤。下载Windows版本kubectl 可以按照官方文档Install kubectl on Windows来下载Windows版本的kubectl命令行。因集群为v1.17.2版本，因此这里直接下载指定版本的kubectl.exe。 curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.17.2/bin/windows/amd64/kubectl.exe 下载好后，配置Windows的PATH，在该环境变量值后增加F:\k8s\bin(该路径为kubectl.exe的目录)。配置好后，打开Git Bash或其他的工具，输入kubectl.exe version --client，可以看到对应的kubectl版本。到这里kubectl就安装好了。下面需要配置kubectl来连接远端Kubernetes集群。 $ kubectl.exe version --client Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.2", GitCommit:"59603c6e503c87169aea6106f57b9f242f64df89", GitTreeState:"clean", BuildDate:"2020-01-18T23:30:10Z", GoVersion:"go1.13.5", Compiler:"gc", Platform:"windows/amd64"} 配置kubectl kubectl需要使用kubeconfig来连接远端集群，通常有三种方式来指定kubeconfig。 ~/.kube/config，默认kubectl会使用该目录。 KUBECONFIG，使用该环境变量的文件。 --kubeconfig，每次执行命令指定kubeconfig文件。这里采用第2种方式。因此在Windows上配置一个环境变量KUBECONFIG。设置KUBECONFIG=F:\k8s\bin\kubeconfig。重新打开Git Bash，执行kubectl.exe get nodes，可以看到连接到了远端的Kubernetes集群。 $ kubectl.exe get nodes NAME STATUS ROLES AGE VERSION meta-k8s-234 Ready master 29m v1.17.2 meta-k8s-235 Ready <none> 28m v1.17.2 meta-k8s-236 Ready <none> 28m v1.17.2 meta-k8s-237 Ready <none> 28m v1.

Kubernetes Dashboard Installation

Dec 12, 2019

Dashboard为Kubernetes官方的一个webui，集合了所有命令行可以操作的资源，可以根据浏览器的语言自动进行语言的识别。通过webui，我们可以更直观的看到Kubernetes集群的运行情况。不过在安装Dashboard的过程中有一些坑，因此在这里整理成文档以便在今后方便查阅。安装 Dashboard的安装相对还是简单的，参考官方的github就可以。 kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml 不过在这中间有一个坑，那就是Dashboard的webui默认是自动生成证书的，由于时间和名称的问题，会导致Chrome和IE等浏览器无法打开界面，这里需要我们自己制作证书处理。开启NodePort kind: Service apiVersion: v1 metadata: labels: k8s-app: kubernetes-dashboard name: kubernetes-dashboard namespace: kube-system spec: ports: - port: 443 targetPort: 8443 nodePort: 30003 selector: k8s-app: kubernetes-dashboard type: NodePort 使用kubectl apply的命令将该service应用在Kubernetes集群中，可以看到该service已经生效。 [root@k8s ~]# kubectl get svc -n kube-system kubernetes-dashboard NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes-dashboard NodePort 10.106.67.12 <none> 443:30003/TCP 40m 通过浏览器访问Dashboard，我们发现无法访问界面，会有类似x.x.x.x通常会使用加密技术来保护您的信息，Google Chrome此次尝试连接到x.x.x.x时，此网站发回了异常的错误凭据。...的字样，更换IE、360浏览器均无法访问，在机器上使用curl -k https://x.x.x.x:30003/命令测试，是可以通的。出现以上现象是因为Dashboard默认为webui生成的证书时间是无效的，时间是过期的，因此需要解决下该问题，以通过浏览器来访问。解决证书过期问题 [root@k8s ~]# openssl genrsa -out dashboard.

Docker容器无法连接外部网络原因排查

Nov 11, 2019

Docker是当前最常用的容器运行时引擎，在使用Kubernetes的过程中，我们使用Docker来负责底层的容器的启动、停止。在用户新安装Docker后的使用过程中，发现通过docker run命令启动的容器，使用默认的bridge网络的情况下，容器无法连接到外部网络，针对这个现象进行排查。缩小问题范围使用 docker run -it --rm alpine:3.6 /bin/sh 启动一个容器，采用bridge网络，在容器内ping外部网络的IP，我们发现是无法ping通，该命令会hang住。退出该容器，再尝试使用host网络启动容器，docker run -it --rm --network=host alpine:3.6 /bin/sh，这次我们发现是可以ping通外部网络的，说明是docker的默认bridge网络有问题，缩小范围。容器使用bridge网络的情况下，在ping外部网络的情况下，如果发送的不是Docker启动创建的docker0的网桥，会进行SNAT，然后使用宿主机的网卡出去，那么怀疑是SNAT可能有问题，因此查看iptables中和Docker相关的规则。命令结果如下： # iptables -t nat -nvL POSTROUTING Chain POSTROUTING (policy ACCEPT 845 packets, 57086 bytes) pkts bytes target prot opt in out source destination 1414 96107 POSTROUTING_direct all -- * * 0.0.0.0/0 0.0.0.0/0 1414 96107 POSTROUTING_ZONES_SOURCE all -- * * 0.0.0.0/0 0.0.0.0/0 1414 96107 POSTROUTING_ZONES all -- * * 0.0.0.0/0 0.0.0.0/0 根据上面结果，我们发现缺少了一条-A POSTROUTING -s 172.

Go开发规范

Oct 10, 2019

代码规范辅助工具 goimports goimports是Go官方提供的工具，能够为我们自动格式化Go语言代码并对引入的包进行管理，其中包括自动增删依赖包引用，将依赖包进行分类排序。 goimports等价于gofmt加依赖包的管理。因此建议所有GO语言开发人员在开发时，使用goimports进行格式化，并在IDE中进行配置，保存时自动格式化。在Goland中进行设置 golint golint是Go官方提供的静态检查工具，该工具的诟病在于可定制化不足，但是在Go的社区中，保证一致性的编程规范是有益的事情，因此该工具大多数用在基础库和框架项目中，上层业务应用可以选用golangci-lint这个工具进行静态检查。建议所有Go语言开发人员在项目中加入golint或golangci-lint工具进行静态检查，甚至于对于基础库和框架来说，可以同时使用上述两个工具来进行检查。自动化无论是上述的格式化还是静态检查，我们都要在我们的CI流程中进行自动化的处理，从而减少代码审核人员的工作，将重心放在代码逻辑上。 Drone结合上述工具进行自动化的示例。项目开发目录结构在项目开发中，Go官方并没有给出一个推荐的目录规划，而在社区中有一些常见的约定，具体的可以看golang-standards/project-layout ，我们也是建议采用该方式进行项目目录规划。 ├── LICENSE ├── Makefile ├── README.md ├── api ├── assets ├── build ├── cmd ├── configs ├── deployments ├── docs ├── examples ├── githooks ├── init ├── internal ├── pkg ├── scripts ├── test ├── third_party ├── tools ├── vendor ├── web └── website 下面介绍常见并且重要的目录及文件。 README.md 该文件写明该项目的简介，功能说明等。 CONTRIBUTING.md 该文件说明其他开发人员如何合作开发该项目。 /pkg 该目录存放的是项目中可以被外部项目或者本项目使用的代码仓库，外部项目直接通过import即可引入该包代码。

[FAQ] 修改configmap后，使用subPath的Pod异常

Sep 9, 2019

Pod状态异常，挂载configmap显示no such file or directory $ kubectl get pod -o wide test-7695dc7fb9-rjxlq 0/1 CrashLoopBackOff 13 17h 192.168.100.20 node1 <none> CrashLoopBackOff状态需要查看pod的日志，通过kubectl logs可以查看到具体的错误信息。 $ kubectl logs -n test-7695dc7fb9-rjxlq container_linux.go:345: starting container process caused "process_linux.go:430: container init caused \"rootfs_linux.go:58: mounting \\\"/var/lib/kubelet/pods/ed1b799a-d3a5-11e9-add6-0894ef725f6e/volume-subpaths/test-cm/app-conf/1\\\" to rootfs \\\"/var/lib/docker/overlay/23a69e27f79f84a14b50fbee1e4840836487f8c740423291c2f785da1e7a6820/merged\\\" at \\\"/var/lib/docker/overlay/23a69e27f79f84a14b50fbee1e4840836487f8c740423291c2f785da1e7a6820/merged/etc/app/app.conf\\\" caused \\\"no such file or directory\\\"\"" 查看日志发现是挂载的configmap有问题。猜测原因：该pod采用subPath的方式挂载configmap，怀疑是configmap修改后，未重建pod导致，因此会出现上述no such file or directory的错误。排查问题查看异常pod的uid，通过下述的命令我们可以看到当前pod在2019-09-10T08:35:21Z的时间创建，并且uid为ed1b799a-d3a5-11e9-add6-0894ef725f6e。 $ kubectl get pod test-7695dc7fb9-rjxlq -o json | jq .metadata { "creationTimestamp": "2019-09-10T08:35:21Z", "generateName": "test-7695dc7fb9-", "labels": { "application": "test", "pod-template-hash": "3251873965" }, "name": "test-7695dc7fb9-rjxlq", "namespace": "openstack", "ownerReferences": [ { "apiVersion": "apps/v1", "blockOwnerDeletion": true, "controller": true, "kind": "ReplicaSet", "name": "test-7695dc7fb9", "uid": "ece58508-d3a5-11e9-add6-0894ef725f6e" } ], "resourceVersion": "1762165", "selfLink": "/api/v1/namespaces/default/pods/test-7695dc7fb9-rjxlq", "uid": "ed1b799a-d3a5-11e9-add6-0894ef725f6e" } 接下来就需要登录到pod所在的节点进行查看。

Mac安装使用Docker

Jun 6, 2019

Docker是目前最常用的容器引擎，在Mac上安装Docker。安装、配置Docker Install Docker Desktop for Mac 按照官方文档直接下载Docker.img并双击安装即可，安装的过程中，需要输入当前用户的登录密码。配置Docker 在Mac上，我们需要先注册Docker ID，进行登录才可以使用。因此我们需要先去https://cloud.docker.com注册自己的账号。 Dockerhub关联Github上的项目关联Github账号进入https://cloud.docker.com，登录自己的账号，然后点击账号的倒三角，看到Account Settings，点击进入设置页面，查看Linked Accounts选项卡，可以关联Github账号，关联好后会显示关联成功。创建Repository 创建好Repository后，点击Builds，设置自动制作镜像的操作。

Coredns简介

Jun 6, 2019

DNS Linux上通过/etc/resolv.conf文件可以配置DNS相关信息，该文件是resovler类库所使用的配置文件，每当通过域名访问其他主机时，该类库会将域名转换为对应的IP，然后才可以进行访问。 resolv.conf 配置 nameserver 该选项用来配置DNS服务器地址，可以指定多个DNS domain 该选项用来指定本地的域名，没有配置search的情况下，search默认使用的为domain的值 search 用来指定多个域名，用空格分隔。当访问的域名无法被DNS服务器解析时，resolver会将该域名后加上search指定的值，重新请求DNS，直到被正确解析或者列表循环结束。 nslookup 默认的超时时间为15s左右。没有配置nameserver 在没有配置任何DNS的情况下，解析域名失败，返回如下错误： $ nslookup baidu.com ;; connection timed out; no servers could be reached 配置nameserver $ cat /etc/resolv.conf nameserver 8.8.8.8 $ nslookup baidu.com Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: baidu.com Address: x.x.x.x Name: baidu.com Address: y.y.y.y 如果没有解析域名成功会有如下信息： $ nslookup aaa.bbb.ccc Server: 8.8.8.8 Address: 8.8.8.8#53 ** server can't find aaa.bbb.ccc: NXDOMAIN DNS常见记录类型 A：指定域名对应的IP地址

Change Etcd cluster member ip

May 5, 2019

背景 Etcd是用于共享配置和服务发现的分布式、满足一致性的KV系统，受到Zookeeper启发，该项目是由CoreOS公司发起。目前在各种云环境中应用广泛，几个比较流行的云项目都采用了Etcd，如CloudFoundry、Kubernetes、Docker。Etcd采用Raft协议进行主节点的选举，并把相应的成员信息存储在各成员的db中。更多关于Etcd的详细介绍，可以在网上或者官方看到，这里不进行相关描述。由于Kubernetes采用Etcd作为后端数据存储，如果Etcd出现问题，会导致整个Kubernetes集群的数据不一致，严重的甚至会导致集群不可用，因此需要掌握Etcd集群的常见问题解决方式，以便在该组件出现故障的时候，可以及时修复，从而保证Kubernetes集群的正常可用，不影响用户的使用。如果Kubernetes集群部署完成后，更新整个集群所有节点的IP地址，当前Kubernetes的控制节点和Etcd成员节点在同一主机上运行，这也意味着如果修改Kubernetes控制节点的IP地址，需要对Etcd集群进行操作，以便Etcd集群可以使用新的IP地址进行通信。因此本文档重点介绍Etcd集群成员变更的两种方式。成员变更解决方式 Etcd集群本身满足(n/2)+1的成员容忍性。下面为集群大小对应的可容忍的异常成员数量。集群大小 Majority 容忍数量 1 1 0 2 2 0 3 2 1 4 3 1 5 3 2 6 4 2 7 4 3 8 5 3 9 5 4 目前我们的Kubernetes集群采用大多数是3节点的Etcd集群，因此允许一个节点失联。下面详细描述下如何进行集群成员IP变更，因为我们的Etcd集群运行在容器中，采用Static Pod的方式由Kubelet进行管理，所以如果Etcd集群部署形态并非容器的话，请根据实际情况进行相应调整，关于etcdctl的操作是一致的，没有区别。我们仍然使用下面的三节点集群，所有节点IP地址如下：成员名称旧IP 新IP master1 192.

预留计算资源

May 5, 2019

Kubernetes Node Allocatable 表示整个集群当前节点pod可用的计算资源量，该配置可以保证调度器不会超额申请计算资源，目前支持CPU,memory,storage这几个参数。 Node Capacity --------------------------- | kube-reserved | |-------------------------| | system-reserved | |-------------------------| | eviction-threshold | |-------------------------| | | | allocatable | | (available for pods) | | | | | --------------------------- https://k8smeetup.github.io/docs/tasks/administer-cluster/out-of-resource/#eviction-policy https://yq.aliyun.com/articles/604524 https://github.com/rootsongjc/qa/issues/3 https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#general-guidelines https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup https://github.com/rancher/rancher/issues/17177 https://github.com/kubernetes/kubernetes/blob/v1.11.6/pkg/kubelet/cm/cgroup_manager_linux.go#L259 http://www.kbase101.com/question/18764.html https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/7/html/resource_management_guide/chap-using_control_groups#sec-Creating_Cgroups https://k8smeetup.github.io/docs/tasks/administer-cluster/reserve-compute-resources/ https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration

Interface

Apr 4, 2019

检测struct类型是否实现了某个接口 package main import "fmt" type Resource interface { GetName() string Restart() } type Pod struct { Name string RestartNumber int } func (p Pod) GetName() string { return p.Name } func (p *Pod) Restart() { p.RestartNumber += 1 } func main() { // 会出现如下的错误: cannot use Pod literal (type Pod) as type Resource in assignment: Pod does not implement Resource (Restart method has pointer receiver) var _ Resource = Pod{} } 因此如果我们想要检测一个类型是否实现了指定的接口，可以通过var _ io.