当使用ingress的方式做Web服务的反向代理时，有时会需要增加对反向页面的权限认证（例如：反向代理到kibana页面时），还好Kubernets非常强大，这么简单的特性当然也是支持的，主要依靠secret和注解方式来实现。 Continue reading "kubernets ingress增加权限HTTP-AUTH认证"
Kubernetes的三种外部访问方式：NodePort、LoadBalancer和Ingress
ClusterIP
官方文档：https://kubernetes.io/docs/concepts/services-networking/service/
ClusterIP 服务是 Kubernetes 的默认服务。它给你一个集群内的服务，集群内的其它应用都可以访问该服务。集群外部无法访问它。
ClusterIP 服务的 YAML 文件类似如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: v1 kind: Service metadata: name: my-internal-service selector: app: my-app spec: type: ClusterIP ports: - name: http port: 80 targetPort: 80 protocol: TCP |
如果 从Internet 没法访问 ClusterIP 服务，那么我们为什么要讨论它呢？那是因为我们可以通过 Kubernetes 的 proxy 模式来访问该服务！
启动 Kubernetes proxy 模式：
|
1 |
$ kubectl proxy --port=8080 |
这样你可以通过Kubernetes API，使用如下模式来访问这个服务：
|
1 |
http://localhost:8080/api/v1/proxy/namespaces//services/<SERVICE-NAME>:<PORT-NAME>/ |
要访问我们上面定义的服务，你可以使用如下地址：
|
1 |
http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/ |
何时使用这种方式？
有一些场景下，你得使用 Kubernetes 的 proxy 模式来访问你的服务：
- 由于某些原因，你需要调试你的服务，或者需要直接通过笔记本电脑去访问它们。
- 容许内部通信，展示内部仪表盘等。
这种方式要求我们运行 kubectl 作为一个未认证的用户，因此我们不能用这种方式把服务暴露到 internet 或者在生产环境使用。 Continue reading "Kubernetes的三种外部访问方式：NodePort、LoadBalancer和Ingress"
在kubernets中不同命名空间的服务相互访问
涉及到的是Pod和Service之间的相互访问，主要格式如下：
|
1 2 3 4 5 6 7 8 9 10 11 |
Pod: {pod-ip}.{namespace}.svc.cluster.local {pod-name}.{namespace}.svc.cluster.local {pod-name}.{subdomain}.{namespace}.svc.cluster.local StatefulSet: {pod-name}.{service-name}.{namespace}.svc.cluster.local 可以进入到pod中查看/etc/hosts Service: {service-name}.{namespace}.svc.cluster.local |
详细请参考官方文档：https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
docker build过程中DNS失效问题解决
该问题是在我使用alpine的apk安装相关软件时发现的，无论如何也无法访问第三方网站，同样在ubuntu中也是如此。
不仅仅是docker build过程中存在DNS解析问题，其实默认在docker运行时，在docker内部也无法和宿主机共享DNS解析服务。
解决方案如下：
|
1 2 3 |
sudo -i echo '{"dns": ["10.0.0.2", "8.8.8.8"]}' > /etc/docker/daemon.json service docker restart |
Kubernetes调度之亲和性和反亲和性
背景
Kubernetes中的调度策略可以大致分为两种，一种是全局的调度策略，要在启动调度器时配置，包括kubernetes调度器自带的各种predicates和priorities算法，具体可以参看文章《Kubernetes调度详解》；另一种是运行时调度策略，包括nodeAffinity（主机亲和性），podAffinity（POD亲和性）以及podAntiAffinity（POD反亲和性）。
nodeAffinity 主要解决POD要部署在哪些主机，以及POD不能部署在哪些主机上的问题，处理的是POD和主机之间的关系。
podAffinity 主要解决POD可以和哪些POD部署在同一个拓扑域中的问题（拓扑域用主机标签实现，可以是单个主机，也可以是多个主机组成的cluster、zone等。），podAntiAffinity主要解决POD不能和哪些POD部署在同一个拓扑域中的问题。它们处理的是Kubernetes集群内部POD和POD之间的关系。
三种亲和性和反亲和性策略的比较如下表所示：
| 策略名称 | 匹配目标 | 支持的操作符 | 支持拓扑域 | 设计目标 |
| nodeAffinity | 主机标签 | In，NotIn，Exists，DoesNotExist，Gt，Lt | 不支持 | 决定Pod可以部署在哪些主机上 |
| podAffinity | Pod标签 | In，NotIn，Exists，DoesNotExist | 支持 | 决定Pod可以和哪些Pod部署在同一拓扑域 |
| PodAntiAffinity | Pod标签 | In，NotIn，Exists，DoesNotExist | 支持 | 决定Pod不可以和哪些Pod部署在同一拓扑域 |
本文主要介绍如何使用亲和性和反亲和性做资源调度。 Continue reading "Kubernetes调度之亲和性和反亲和性"
kubectl 命令自动补全
在k8s 1.3版本之前，设置kubectl命令自动补全是通过以下的方式：
|
1 |
source ./contrib/completions/bash/kubectl |
但是在k8s 1.3版本，源码contrib目录中已经没有了completions目录，无法再使用以上方式添加自动补全功能。
1.3版本中，kubectl添加了一个completions的命令， 该命令可用于自动补全
|
1 |
source <(kubectl completion bash) |
通过以上方法进行配置了，便实现了kubectl的自动补全。
helm简介、安装、使用
Helm简介
利用Kubernetes部署一个应用，需要Kubernetes原生资源文件如deployment、replicationcontroller、service或pod 等。而对于一个复杂的应用，会有很多类似上面的资源描述文件，如果有更新或回滚应用的需求，可能要修改和维护所涉及的大量资源文件，且由于缺少对发布过的应用版本管理和控制，使Kubernetes上的应用维护和更新等面临诸多的挑战，而Helm可以帮我们解决这些问题。
Helm架构
Helm基本架构如下：
Helm用途
做为Kubernetes的一个包管理工具，Helm具有如下功能：
- 创建新的chart
- chart打包成tgz格式
- 上传chart到chart仓库或从仓库中下载chart
- 在Kubernetes集群中安装或卸载chart
- 管理用Helm安装的chart的发布周期
Helm有三个重要概念：
- chart：包含了创建Kubernetes的一个应用实例的必要信息
- config：包含了应用发布配置信息
- release：是一个chart及其配置的一个运行实例
开启crontab日志功能
修改rsyslog
|
1 |
sudo vim /etc/rsyslog.d/50-default.conf |
|
1 2 |
cron.* /var/log/cron.log #将cron前面的注释符去掉 |
重启rsyslog
|
1 |
sudo service rsyslog restart |
查看crontab日志
|
1 |
less /var/log/cron.log |
filebeat相关语法命令
Filebeat提供了一个用于运行Beat和执行常见任务的命令行界面，如测试配置文件和加载仪表板。 命令行还支持用于控制全局行为的全局标志。
常用的filebeat命令：
-E, --E "SETTING_NAME=VALUE"
覆盖特定的配置设置。 您可以指定多个覆盖。 例如：
|
1 |
filebeat -E "name=mybeat" -E "output.elasticsearch.hosts=["http://myhost:9200"]" |
此设置适用于当前正在运行的Filebeat进程。 Filebeat配置文件不会更改。
-M, --M "VAR_NAME=VALUE"
覆盖Filebeat模块的默认配置。 您可以指定多个变量覆盖。 例如：
|
1 |
filebeat -modules=nginx -M "nginx.access.var.paths=[/var/log/nginx/access.log*]" -M "nginx.access.var.pipeline=no_plugins" |
-c, --c FILE
指定用于Filebeat的配置文件。 你在这里指定的文件是相对于path.config。 如果未指定-c标志，则使用默认配置文件filebeat.yml(Ubuntu下默认为 /etc/filebeat/filebeat.yml)。需要注意的是，配置文件的权限必须为644，并且拥有者必须为root。
-d, --d SELECTORS
启用对指定选择器的调试。 对于选择器，可以指定逗号分隔的组件列表，也可以使用-d“*”为所有组件启用调试。 例如，-d "publish" 显示所有 "publish" 相关的消息。
-e, --e
记录到stderr并禁用syslog /文件输出。
-v, --v
记录INFO级别的消息。 Continue reading "filebeat相关语法命令"
logrotate日志管理工具
日志实在是太有用了，它记录了程序运行时各种信息。通过日志可以分析用户行为，记录运行轨迹，查找程序问题。可惜磁盘的空间是有限的，就像飞机里的黑匣子，记录的信息再重要也只能记录最后一段时间发生的事。为了节省空间和整理方便，日志文件经常需要按时间或大小等维度分成多份，删除时间久远的日志文件。这就是通常说的日志滚动(log rotation)。
最近整理nginx日志，用了一个类Unix系统上的古老工具——logrotate，发现意外的好用。想了解这个工具的用法推荐看这里。我了解了一下这个工具的运行机制和原理，觉得挺有趣的。 Continue reading "logrotate日志管理工具"