云原生知识星球

YAML处理工具yq之安装篇

发表于 2019-08-02 更新于 2024-11-02 分类于 tools 阅读时长 ≈ 1 分钟

yq是一个轻量级的便携式命令行YAML处理器。该工具的目标是成为yaml文件处理方面的jq或sed。

安装

在MacOS上：

1	brew install yq

在Ubuntu和支持snap包的其他Linux发行版上：

1	snap install yq

在Ubuntu 16.04或更高版本上：

1
2
3

sudo add-apt-repository ppa:rmescandon/yq
sudo apt update
sudo apt install yq -y

或者，下载最新的二进制文件或者：

1	go get gopkg.in/mikefarah/yq.v2

View on GitHub

在Eclipse JPA的persistence.xml中设置环境变量

发表于 2019-07-31 更新于 2024-11-02 分类于 db 阅读时长 ≈ 1 分钟

需求

我们都知道，在使用EclipseLink JPA操作数据库时，不可或缺的要配置persistence.xml文件，一个最基本的配置示例如下：

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.1"
	xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
	<persistence-unit name="JPAExamples">
	  <class>com.lyyao.jpa.test.Employee</class>
	  <properties>
		<property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver"/>
		<property name="javax.persistence.jdbc.url" value="jdbc:mysql://192.168.0.1:3306/employee"/>
		<property name="javax.persistence.jdbc.user" value="root"/>
		<property name="javax.persistence.jdbc.password" value="123456"/>
	  </properties>
	</persistence-unit>
</persistence>

那么问题来了，对于数据库的IP地址，端口号，用户名和密码这几个参数：

在这里定义死合适吗？
如果需要根据实际环境变化怎么办？

所以，有没有一种方法，可以在上面的配置文件里定义变量或默认值，然后根据实际环境获取变量的值取覆盖呢？

答案是有的。从查阅的资料看，我了解到有2种方法可以解决上面的问题。

解决方法

方法一：默认值覆盖法

通过Persistence.createEntityManagerFactory(PERSISTENCE_UNIT_NAME,properties)方法注入properties参数，该

方法二：变量替换法

参考

https://dzone.com/articles/jpa-with-eclipselink-amp-mysql-using-java-configur

https://gist.github.com/baumato/3283f255b00094411110fc889be58aa5

如何从Pod容器中访问Kubernetes API服务

发表于 2019-07-31 更新于 2024-11-02 分类于 stackoverflow 阅读时长 ≈ 1 分钟

问题描述

我之前可以使用curl执行如下命令：

1	https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_PORT_443_TCP_PORT/api/v1beta3/namespaces/default/

但在kubernetes 0.18.0中它提示“unauthorized”。奇怪的是，如果我使用外部IP地址（http://172.17.8.101:8080/api/v1beta3/namespaces/default/）是可以访问的。

高票回答

在官方文档中我发现了这个：

显然，我没有在之前版本的Kubernetes中使用安全令牌。从那时起，我设计了一个比运行代理或在容器上安装golang更简单的解决方案。请参阅此示例，该示例从api获取当前容器的信息：

1
2
3

KUBE_TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
curl -sSk -H "Authorization: Bearer $KUBE_TOKEN" \
https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_PORT_443_TCP_PORT/api/v1/namespaces/default/pods/$HOSTNAME

我还使用包含一个简单的二进制文件jq来解析json以用于bash脚本。

原文链接

How do I access the Kubernetes api from within a pod container?

如何强制Kubernetes预拉取镜像

发表于 2019-07-31 更新于 2024-11-02 分类于 stackoverflow 阅读时长 ≈ 1 分钟

问题描述

我在GKE上的Kubernetes中有以下rc控制器：

apiVersion: v1
kind: ReplicationController
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 2
  selector:
    app: myapp
    deployment: initial
  template:
    metadata:
      labels:
        app: myapp
        deployment: initial
    spec:
      containers:
      - name: myapp
        image: myregistry.com/myapp:5c3dda6b
        ports:
        - containerPort: 80
      imagePullPolicy: Always
      imagePullSecrets:
        - name: myregistry.com-registry-key

现在，如果我执行以下命令执行滚动更新，但没有重新拉镜像。为什么？

1	kubectl rolling-update myapp --image=us.gcr.io/project-107012/myapp:5c3dda6b

高票回答

如果有如下定义，Kubernetes将会在Pod创建时拉取镜像（请参阅更新镜像文档）：

镜像的标签为:latest
指定镜像的拉取策略imagePullPolicy: Always

如果你想每次都拉取镜像，这很好。但是，如果您想按需执行该操作：例如，如果您想使用some-public-image：latest，但只想在请求时手动提取新版本。你现在可以：

将imagePullPolicy设置为IfNotPresent或Never并提前拉取好，在每个群集节点上手动拉取镜像，以便是最新版本，然后执行kubectl rolling-update或类似重启Pods
暂时更改imagePullPolicy，执行kubectl apply，重新启动pod（例如kubectl rolling-update），还原imagePullPolicy，重新kubectl apply
将一些some-public-image:latest推送到您的私有存储库并执行kubectl rolling-update

按需拉动没有好的解决方案。如果有变化，请评论，我会更新这个答案。

原文链接

How do I force Kubernetes to re-pull an image?

Marathon vs Kubernetes vs Docker Swarm

发表于 2019-07-30 更新于 2024-11-02 分类于 stackoverflow 阅读时长 ≈ 1 分钟

问题描述

我正在寻找在DC / OS上运行Docker容器时是否使用Marathon和Chronos，Docker Swarm或Kubernetes的一些优缺点。

例如，何时使用Marathon / Chronos比使用Kubernetes更好，反之亦然？

现在我主要是进行实验，但希望我们在夏天之后开始在生产中使用这些服务之一。这可能会使Docker Swarm失去资格，因为我不确定它是否会在那时处于生产可用。

我喜欢Docker Swarm的原因是它本质上只是“Docker命令”，你不需要学习全新的东西。我们已经在使用docker-compose，它将与Docker Swarm一起开箱即用（至少在理论上），这将是一个很大的优势。我对Docker Swarm的主要关注是它是否涵盖了在生产中运行系统所需的所有用例。

高票回答

我将尝试分解Mesos上每个容器编排框架的独特方面。

使用Docker Swarm，如果：

您想使用熟悉的Docker API在Mesos上启动Docker容器
Swarm最终可能会提供一个API来与Kubernetes（甚至是K8s-Mesos）交互
请参阅：http://www.techrepublic.com/article/docker-and-mesos-like-peanut-butter-and-jelly/

使用Kubernetes-Mesos，如果：

您想要启动K8s Pods，它们是共同调度的容器组，共享资源
您希望与父容器旁边的一个或多个sidekick容器（例如，日志归档程序，度量标准监视器）一起启动服务
您希望使用基于K8s标签的服务发现，负载平衡和副本控制
请参阅：http://kubernetesio.blogspot.com/2015/04/kubernetes-and-mesosphere-dcos.html

使用Marathon，如果：

您想要启动Docker或非Docker长期运行的应用程序/服务
您希望将Mesos属性用于基于约束的计划
您希望使用应用程序组和依赖关系来启动，扩展或升级相关服务
您希望使用运行状况检查来自动重新启动不健康的服务或回滚不健康的部署/升级
您希望集成HAProxy或Consul以进行服务发现
您希望通过Web UI或REST API启动和监控应用程序
您想要使用从一开始就构建的框架

使用Chronos，如果：

您希望启动预期退出的Docker或非Docker任务
您希望将任务计划为在特定时间/计划（cron）运行
您希望安排依赖任务的DAG工作流程
您希望通过Web UI或REST API启动和监视作业
您想要使用从一开始就构建的框架

原文链接

Marathon vs Kubernetes vs Docker Swarm on DC/OS with Docker containers

Kubernetes vs. CloudFoundry

发表于 2019-07-29 更新于 2024-11-02 分类于 stackoverflow 阅读时长 ≈ 2 分钟

问题描述

CloudFoundry / Diego的下一个版本将为Docker容器提供原生支持，这些容器将在多个主机[链接]之间进行编排。这听起来与Kubernetes非常相似。

当然，Kubernetes试图解决的问题更为通用，其中CloudFoundry更专注于应用程序开发。然而，对我来说，它听起来都朝着类似的方向发展，而CloudFoundry正在简单的业务流程之上添加更多功能。

所以，我想知道Kubernetes会比CloudFoundry增加更多有价值的用例吗？

高票回答

作为CloudFoundry（过去）和Kubernetes（现在）的提交者，我可能有资格回答这个问题。

PaaS平台

我喜欢将CloudFoundry称为“应用程序PaaS”，将Kubernetes称为“容器PaaS”，但鉴于两个项目都会随着时间的推移而在同一市场中竞争，因此区别相当微妙和流畅。

两者之间的区别在于CF有一个暂存层，它采用（12-factor）用户应用程序（例如jar或gem）和Heroku风格的buildpack（例如Java + Tomcat或Ruby）并生成一个Droplet（类似于Docker镜像）。CF不会将容器化接口暴露给用户，但Kubernetes会这样做。

受众人员

CloudFoundry的主要受众是希望使用Heroku风格的buildpack部署12-factor无状态应用程序的企业应用程序开发人员。

Kubernetes的受众范围更广，包括无状态应用程序和提供自己容器的有状态服务开发人员。

这种区别可能在未来发生变化：

CloudFoundry开始接受docker镜像
Kubernetes可以添加镜像生成层

功能比较

随着两个项目的成熟和竞争，它们的异同将发生变化。因此，请将以下特征进行比较。

CF和K8都有许多相似的功能，如容器化，命名空间，身份验证。

Kubernetes的竞争优势：

对共享网络堆栈的容器进行分组和扩展，而不是仅仅进行独立扩展
提供自己的容器
有状态持久层
更大、更活跃的OSS社区
具有可替换组件和第三方插件
免费的web GUI

CloudFoundry的竞争优势：

成熟的身份验证，用户分组和多租户支持[x]
提供自己的APP
包括负载均衡器
由BOSH部署，扩展并保持状态[x]
强大的日志记录和度量聚合[x]
企业Web GUI [x]

[x] 这些功能不是Diego的一部分或包含在Lattice中。

部署

CloudFoundry的竞争优势之一是它拥有成熟的部署引擎BOSH，可以实现核心CF组件的扩展，恢复和监控等功能。BOSH还支持许多具有可插拔云提供程序抽象的IaaS层。不幸的是，BOSH的学习曲线和部署配置管理是噩梦。（作为BOSH提交者，我想我可以准确地说出来。）

Kubernetes的部署抽象仍处于起步阶段。核心仓库中提供了多个目标环境，但它们并非全部正在运行，经过良好测试或得到主要开发人员的支持。这主要是成熟的事情。人们可能会期望这会随着时间的推移而改进并且会增加抽象。例如，DCOS上的Kubernetes允许使用单个命令将Kubernetes部署到现有DCOS群集。

历史背景

Diego是CF的Droplet执行代理的重写。它最初是在Kubernetes宣布之前开发的，随着竞争格局的演变，它已经具有更多的功能范围。它的最初目标是生成droplets（用户应用程序 + CF buildpack）并在Warden（在Go中重写时重命名为Garden）容器中运行它们。自成立以来，它也被重新打包为Lattice，它有点像CloudFoundry-lite（虽然这个名字是由现有项目拍摄的）。出于这个原因，Lattice有点像玩具一样，因为它故意减少了用户的观众和范围，显然缺少使其达到“企业就绪”的功能。CF已经提供的功能。这部分是因为Lattice用于测试核心组件，而没有来自更复杂的CF的一些开销，但您也可以在内部高信任环境中使用Lattice，其中安全性和多租户不是那么重要。

值得一提的是，CloudFoundry和Warden（它的容器引擎）也早于Docker，差不多几年了。

另一方面，Kubernetes是一个相对较新的项目，由Google根据BORG和Omega多年的容器使用情况开发而成。Kubernetes可以被认为是谷歌的第三代容器编排，就像Diego是Pivotal / VMware的第三代容器编排一样（v1在VMware编写; v2在VMware与Pivotal Labs帮助; v3在Pivotal接管项目后）。

原文链接

Kubernetes vs. CloudFoundry

如何创建一个本地的Kubernetes开发环境

发表于 2019-07-27 更新于 2024-11-02 分类于 stackoverflow 阅读时长 ≈ 1 分钟

问题描述

Kubernetes似乎都是将容器部署到集群云中。它似乎没有提及开发和临时环境（或类似环境）。

在开发期间，您希望尽可能接近生产环境并进行一些重要更改：

在本地部署（或至少在您和您可以访问的地方部署）
在页面刷新时使用最新的源代码（假设它是一个网站；理想情况下，本地文件保存页面自动刷新，如果您安装源代码并使用像Yeoman这样的东西可以完成）

同样，人们可能希望在非公共环境进行持续集成。

Kubernetes是否支持这种开发环境，或者是必须构建的东西，希望在生产过程中它仍然可以工作？

高票回答

更新（2016-07-15）

随着Kubernetes 1.3的发布，Minikube现在是在本地机器上运行Kubernetes进行开发的推荐方式。

原文链接

How to create a local development environment for Kubernetes?

Ingress vs LoadBalancer

发表于 2019-07-27 更新于 2024-11-02 分类于 stackoverflow 阅读时长 ≈ 2 分钟

问题描述

我很困惑Ingress和Load Balancer在Kubernetes中的角色。

据我所知，Ingress用于将来自互联网的传入流量映射到群集中运行的服务。

Load Balancer的作用是将流量转发到主机。在这方面，Ingress与Load Balancer有何不同？与Amazon ELB和ALB相比，kubernetes中的Load Balancer的概念是什么？

高票回答

Load Balancer：kubernetes LoadBalancer是指向不在您的kubernetes集群中但存在于其他地方的外部负载均衡器的服务。假设您的pod可以从外部路由，它们可以与您的pod一起使用。Google和AWS本身就提供此功能。就Amazon而言，在AWS中运行时直接映射到ELB，kubernetes可以为部署的每个LoadBalancer服务自动配置和配置ELB实例。

Ingress：Ingress实际上只是将一组规则传递给正在监听它们的控制器。您可以部署一组Ingress规则，但除非您有可以处理它们的控制器，否则不会发生任何事情。如果配置为执行此操作，则LoadBalancer服务可以侦听Ingress规则。

您还可以创建NodePort服务，该服务在群集外部具有可外部路由的IP，但指向群集中存在的Pod。这可能是一个Ingress控制器。

Ingress Controller只是一个配置为解释入口规则的pod。nginx是kubernetes支持的最受欢迎的Ingress控制器之一。就亚马逊而言，ALB可用作Ingress控制器。

例如，这个nginx控制器能够获取你定义的入口规则并将它们转换为一个nginx.conf文件，它在它的pod中加载和启动。比如说你定义了一个Ingress如下：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
   ingress.kubernetes.io/rewrite-target: /
 name: web-ingress
spec:
  rules:
  - host: kubernetes.foo.bar
    http:
      paths:
      - backend:
          serviceName: appsvc
          servicePort: 80
        path: /app

然后，如果您检查nginx控制器的pod，您将在/etc/nginx.conf中看到定义的以下规则:

server {
    server_name kubernetes.foo.bar;
    listen 80;
    listen [::]:80;
    set $proxy_upstream_name "-";
    location ~* ^/web2\/?(?<baseuri>.*) {
        set $proxy_upstream_name "apps-web2svc-8080";
        port_in_redirect off;

        client_max_body_size                    "1m";

        proxy_set_header Host                   $best_http_host;

        # Pass the extracted client certificate to the backend

        # Allow websocket connections
        proxy_set_header                        Upgrade           $http_upgrade;
        proxy_set_header                        Connection        $connection_upgrade;

        proxy_set_header X-Real-IP              $the_real_ip;
        proxy_set_header X-Forwarded-For        $the_x_forwarded_for;
        proxy_set_header X-Forwarded-Host       $best_http_host;
        proxy_set_header X-Forwarded-Port       $pass_port;
        proxy_set_header X-Forwarded-Proto      $pass_access_scheme;
        proxy_set_header X-Original-URI         $request_uri;
        proxy_set_header X-Scheme               $pass_access_scheme;

        # mitigate HTTPoxy Vulnerability
        # https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
        proxy_set_header Proxy                  "";

        # Custom headers

        proxy_connect_timeout                   5s;
        proxy_send_timeout                      60s;
        proxy_read_timeout                      60s;

        proxy_redirect                          off;
        proxy_buffering                         off;
        proxy_buffer_size                       "4k";
        proxy_buffers                           4 "4k";

        proxy_http_version                      1.1;

        proxy_cookie_domain                     off;
        proxy_cookie_path                       off;

    rewrite /app/(.*) /$1 break;
    rewrite /app / break;
    proxy_pass http://apps-appsvc-8080;

    }

Nginx刚刚创建了一条规则来路由http://kubernetes.foo.bar/app以指向群集中的服务appsvc。

示例介绍了如何在kubernetes集群中使用nginx ingress控制器。希望这可以帮助！

原文链接

Ingress vs Load Balancer

Kubernetes的各种Service类型（ClusterIP，NodePort和LoadBalancer）有什么区别

发表于 2019-07-27 更新于 2024-11-02 分类于 stackoverflow 阅读时长 ≈ 1 分钟

问题描述

1 - 我正在阅读文档，我对措辞有点困惑。它说：

ClusterIP：在集群内部IP上公开服务。选择此值使服务只能从群集中访问。这是默认的ServiceType

NodePort：在每个Node的IP上公开静态端口（NodePort）服务。将自动创建NodePort服务到ClusterIP服务的路由。您可以通过请求：来从群集外部请求NodePort服务。

LoadBalancer：使用云提供商的负载均衡器在外部公开服务。将自动创建外部负载均衡器到NodePort和ClusterIP服务的路由。

NodePort服务类型是否仍然使用ClusterIP，而只是在不同的端口，该端口对外部客户端开放？那么在这种情况下，：与：相同？

或者，NodeIP是否是运行kubectl get nodes得到的IP，而不是用于ClusterIP的虚拟IP？

2 - 同样在以下链接的图表中：

http://kubernetes.io/images/docs/services-iptables-overview.svg

客户端在节点内是否有任何特殊原因？我认为在ClusterIP服务类型的情况下，它需要在Cluster内。如果为NodePort绘制一个类似的图表，那么把客户端画在Node和Cluster之外是否有效，或者我是否忽略了什么？

高票回答

ClusterIP公开以下内容：

spec.clusterIp:spec.ports[*].port

您只能在群集内访问此服务。可以从spec.clusterIp端口访问它。如果设置了spec.ports [*].targetPort，它将从端口路由到targetPort。调用kubectl get services时获得的CLUSTER-IP是内部在集群内分配给此服务的IP。

NodePort公开以下内容：

<NodeIP>:spec.ports[*].nodePort
spec.clusterIp:spec.ports[*].port

如果通过nodePort的方式从节点的外部IP访问此服务，它会将请求路由到spec.clusterIp:spec.ports[*].port，然后将其路由到spec.ports [*].targetPort，如果设置。也可以使用与ClusterIP相同的方式访问此服务。

您的NodeIP是节点的外部IP地址。您无法从:spec.ports [*].nodePort访问您的服务。

LoadBalancer公开以下内容：

spec.loadBalancerIp:spec.ports[*].port
<NodeIP>:spec.ports[*].nodePort
spec.clusterIp:spec.ports[*].port

您可以从负载均衡器的IP地址访问此服务，该IP地址将您的请求路由到nodePort，而nodePort又将请求路由到clusterIP端口。您可以像访问NodePort或ClusterIP服务一样访问此服务。

原文链接

What’s the difference between ClusterIP, NodePort and LoadBalancer service types in Kubernetes

Docker-Swarm，Kubernetes，Mesos和Core-OS Fleet

发表于 2019-07-27 更新于 2024-11-02 分类于 stackoverflow 阅读时长 ≈ 1 分钟

问题描述

我对所有这些都比较陌生，并且在尝试理解列出的这些技术时遇到了麻烦。

虽然，所有这些技术都试图解决不同的问题，但也有共同点。我想了解哪些是相同的，哪些是不同的。少数技术的组合很可能非常适合，如果是这样的话，他们是什么？

我列出了其中的一些以及问题，但如果有人详细列出所有问题并回答问题，那将会很棒。

Kubernetes vs Mesos:

Apache的Mesos和Google的Kubernetes有什么区别提供了很好的洞察力，但我无法理解为什么Kubernetes应该运行在Mesos之上。两个开源解决方案的结合更多的是什么？
Kubernetes vs Core-OS Fleet:

如果我使用kubernetes，是否需要Core-OS Fleet？
Docker-Swarm如何适应上述所有内容？

高票回答

我认为Mesos和Kubernetes主要是为了解决运行集群应用程序的类似问题，他们有不同的历史和解决问题的不同方法。

Mesos将精力集中在非常通用的调度上，并插入多个不同的调度程序。这意味着它使Hadoop和Marathon等系统能够在同一个调度环境中共存。Mesos不太关注运行时容器。Mesos存在于对容器的广泛关注之前，并且已经重新更新以支持容器。

相比之下，Kubernetes从一开始就被设计成一个用于从容器构建分布式应用程序的环境。它包括用于复制和服务发现的原语作为核心原语，其中 - 在Mesos中是通过框架添加这些原语。Kubernetes的主要目标是构建，运行和管理分布式系统的系统。

Fleet是一个较低级别的任务分发者。它对于引导群集系统很有用，例如CoreOS使用它将kubernetes代理和二进制文件分发到群集中的计算机，以便启动kubernetes群集。它并不是真正意图解决相同的分布式应用程序开发问题，更像是集群的systemd / init.d / upstart。如果您运行kubernetes，则不需要它，您可以使用其他工具（例如Salt，Puppet，Ansible，Chef，…）来完成相同的二进制分发。

Swarm是Docker努力扩展现有的Docker API，使一组机器看起来像一个Docker API。从根本上说，我们在Google和其他地方的经验表明，节点API不足以支持群集API。你可以在这里看到一堆讨论：
https://github.com/docker/docker/pull/8859和这里：
https://github.com/docker/docker/issues/8781

原文链接

Docker-Swarm, Kubernetes, Mesos & Core-OS Fleet