我的问题(对MS和其他任何人)是:为什么这个问题发生了,用户/客户自己可以实现哪些解决方案而不是Microsoft支持？

关于这个问题,显然有一些"其他"问题:

1. 托管Azure Kubernetes连接错误
2. 无法联系我们的Azure-AKS kube - TLS握手超时
3. Azure Kubernetes:TLS握手超时(这个有一些微软反馈)

多个GitHub问题发布到AKS回购:

1. https://github.com/Azure/AKS/issues/112
2. https://github.com/Azure/AKS/issues/124
3. https://github.com/Azure/AKS/issues/164
4. https://github.com/Azure/AKS/issues/177
5. https://github.com/Azure/AKS/issues/324

加上一些推特线程:

1. https://twitter.com/ternel/status/955871839305261057

TL; DR

跳到下面的答案中的解决方法.

目前最好的解决方案是发布帮助票 - 等待 - 或重新创建你的AKS集群(可能不止一次,交叉你的手指,见下文......)但应该有更好的东西.至少请授予AKS预览客户的能力,无论支持层如何,都要升级其针对此特定问题的支持请求严重性.

您还可以尝试扩展群集(假设不会破坏您的应用).

GitHub怎么样？

许多上述Gi​​tHub问题已经解决,但问题仍然存在.以前有一个关于这个问题的公告文件,但是目前还没有这样的状态更新,即使问题仍然存在:

1. https://github.com/Azure/AKS/tree/master/annoucements

我发布这个,因为我有一些我没有在其他地方看到的新花絮,我想知道是否有人有想法解决问题的其他潜在选择.

受影响的VM /节点资源使用情况

我在其他地方没有提到的第一篇文章是节点/ vms /实例上的资源使用情况,这些资源使用受上述Kubectl"无法连接到服务器:net/http:TLS握手超时"问题的影响.

生产节点利用率

我受影响的集群上的节点如下所示:

利用率和网络的下降与磁盘利用率的增加和我们开始遇到问题的时间段密切相关.

在此图表之前的整个节点/ VM利用率在过去30天内基本持平,并且与生产站点流量/更新推送等相关的一些颠簸.

减轻问题后的度量标准(已添加事后检查)

对于上述观点,以下是在扩展然后退回之后相同节点的指标(这恰好缓解了我们的问题,但并不总是有效 - 请参见底部的答案):

请注意CPU和网络中的"Dip"？ 这就是Net/http:TLS问题影响我们的地方 - 以及何时从Kubectl无法访问AKS服务器.似乎除了没有响应我们的请求之外,它还没有与VM/Node通信.

一旦我们回来(将#个节点向上扩展,然后退回 - 查看解决方法的答案),度量标准(CPU等)恢复正常 - 我们可以从Kubectl连接.这意味着我们可以创建一个关于此行为的警报(我在Azure DevOps方面询问此问题:https://github.com/Azure/AKS/issues/416)

节点大小可能会影响发布频率

Zimmergren在GitHub上结束表明他在更大的实例上遇到的问题少于运行裸骨小节点的问题.这对我来说很有意义,并且可能表明AKS服务器分配工作负载的方式(参见下一节)可能基于实例的大小.

"节点的大小(例如D2,A4等):)我经历过,当运行A4及以上时,我的群集比运行A2时更健康.(而且我有十几个类似的不幸的是,经历了大小组合和集群故障." (https://github.com/Azure/AKS/issues/268#issuecomment-375715435)

其他群集大小影响参考:

1. giorgited(https://github.com/Azure/AKS/issues/268#issuecomment-376390692)

负责更小型集群的AKS服务器可能会更频繁地受到攻击？

一个Az区域中多个AKS管理'服务器'的存在

我在其他地方没有提到的下一件事是你可以在同一个区域并排运行多个集群,其中一个集群(在这种情况下为我们生产)被'net/http:TLS握手超时'命中另一个工作正常,可以通过Kubectl正常连接(对我们来说这是我们相同的临时环境).

用户(上面的Zimmergren等)似乎认为节点大小影响此问题将影响您的可能性这一事实似乎也表明节点大小可能与子区域责任分配给子区域AKS的方式有关管理服务器.

这可能意味着重新创建具有不同群集大小的群集将更有可能将您置于不同的管理服务器上 …

我们以前的基于GitLab的CI/CD使用Authenticated curl请求到特定的REST API端点,以触发将更新的容器重新部署到我们的服务,如果您使用类似于基于Kubernetes的部署,则此问题适合您.

更多背景

我们在Azure AKS群集上运行生产站点/应用程序(基于Ghost博客).现在我们手动将更新的容器推送到私有ACR(Azure容器注册表),然后使用Kubectl从命令行进行更新.

话虽如此,我们之前使用Docker Cloud进行编排,并使用Gi​​tLab-Ci完全集成了我们的生产/登台服务.

GitLab-Ci集成是目标,而"为什么"背后是这个问题.

我的问题

由于我们之前使用过Docker Cloud(doh,应该从一开始就使用K8),我们应该如何处理GitLab-Ci能够利用Secrets创建Docker Cloud CLI然后使用Docker Cloud API进行身份验证以触发操作的事实在我们的节点上(即用新容器重新部署等).

虽然我相信我们可以构建一个容器(由我们的GitLab-Ci运行器使用),其中包含Kubectl和Azure CLI,但我知道Kubernetes也有类似的(对于docker cloud)Rest API,可以在这里找到(https ://kubernetes.io/docs/tasks/access-application-cluster/access-cluster) - 特别是关于连接WITHOUT Kubectl的部分似乎是相关的(关于HTTP REST API的部分).

我的问题是任何连接到Azure(或可能是其他托管Kubernetes服务)的人:

您的Ci/CD服务器如何通过Kubernetes服务提供商的Management Server进行身份验证,然后您如何触发更新/重新部署更新的容器/服务？

如果您使用Kubernetes HTTP Rest API重新部署服务,那么您的想法特别有价值!

我正在审查Kubernetes资源

1. 我应该如何使用kubernetes管理部署
2. Kubernetes部署

在我完成整个过程时会更新.

我目前正致力于从Node应用程序解析远程csv产品供稿,并希望使用Papa Parse来做到这一点(因为我过去在浏览器中取得了成功).

Papa Parse Github:https://github.com/mholt/PapaParse

我最初的尝试和网络搜索并没有准确地说明如何做到这一点.Papa自述文件说Papa Parse现在与Node兼容,因此Baby Parse(用于提供一些节点解析功能)已被折旧.

这是一个指向文档节点部分的链接,适用于将来在这个问题上绊倒的人:https://github.com/mholt/PapaParse#papa-parse-for-node

从该doc段开始,看起来Node中的Papa Parse可以解析可读流而不是File.我的问题是;

有没有办法利用可读流功能来使用Papa下载/解析Node中的远程CSV,这与浏览器中的Papa如何使用XMLHttpRequest实现同样的目标有什么相似之处？

对于未来可见性 对于那些搜索该主题(并避免重复类似问题)的人,尝试利用此处描述的远程文件解析功能:http://papaparse.com/docs#remote-files将导致您的以下错误安慰:

"未处理的拒绝ReferenceError:未定义XMLHttpRequest"

我已经在官方存储库上打开了一个问题,并将更新此问题,因为我了解了有关需要解决的问题的更多信息.

我有一个工作群集服务,所有服务都响应安装在Azure AKS上运行的Ingress nGinx掌舵.这最终是Azure特定的.

我的问题是:为什么我与此群集中的服务/ pod的连接会定期被切断(显然是通过某种空闲超时),为什么该连接断开似乎也与我的Az AKS Browse UI连接被切断一致？

这是为了获得最终答案,以确定触发导致本地"浏览"代理UI与我的群集断开连接的超时(更多背景为什么我要求遵循).

从Az CLI使用Azure AKS时,您可以使用以下命令从终端启动本地浏览UI:

az aks browse --resource-group <resource-group> --name <cluster-name>

这工作正常,弹出一个看起来像这样的浏览器窗口(yay):

在您的终端中,您将看到以下内容:

1. 代理在http://127.0.0.1:8001/上运行按CTRL + C关闭隧道...
2. 转发自127.0.0.1:8001 - > 9090转发自
3. [:: 1]:8001 - > 9090处理8001的连接处理8001处理连接8001的连接

如果您将与群集的连接空闲几分钟(即,您不与UI交互),您应该看到以下打印以指示连接已超时:

E0605 13:39:51.940659 5704 portforward.go:178]丢失了与pod的连接

我仍然不明白的一件事是,群集内的其他活动是否可以延长此超时时间,但无论您何时看到上述内容,您基本上都处于相同的位置...这意味着我们可以谈论它看起来的事实就像我所有的其他连接一样,来自该服务器中的pod的OUT也被任何超时过程关闭,该过程负责切断与AKS浏览UI的联系.

那么问题是什么？

这对我来说是个问题的原因是我有一个服务运行Ghost Blog pod,它使用名为'Knex'的npm包连接到远程MySQL数据库.碰巧新版本的Knex有一个bug(尚未解决),如果Knex客户端和远程数据库服务器之间的连接被切断并需要恢复 - 它不会重新连接,只是无限制负载.

nGinx错误503网关超时

在我的情况下导致nGinx Ingress给我一个Error 503 Gateway超时.这是因为在空闲超时切断Knex连接后Ghost没有响应 - 因为Knex无法正常工作并且没有正确恢复与服务器的断开连接.

精细. 我回滚了Knex,一切都很好.

但是为什么我的pod连接从我的数据库中被切断开始呢？

因此,这个问题希望能够节省一些未来的人们试图解决与Kubernetes(可能是Azure特定的,可能不是)相关的幻像问题的日子,这些问题在服务/ pod已经闲置一段时间之后切断了连接.

因此，在谷歌搜索了一下之后（这被人们对Pull Secrets的麻烦所污染），我将其发布在这里-以及GCP支持（据我所知将会更新）。

我通过GitLab Kubernetes集成（文档：https：//about.gitlab.com/solutions/kubernetes ）在与我的GCR注册表/图像相同的项目中创建了一个集群。

当我使用Kubectl（依赖于该项目中GCR注册表中的私有映像）向该集群添加新服务/部署时，GitLab创建的集群中的Pod无法通过以下方式从GCR中提取：ErrImagePull。

需要明确的是，我不是从GitLab私有注册表中拉出，而是在与从GitLab创建的GKE集群（不需要拉出秘密）相同的项目中，从GCR注册表中拉出。

该项目中的其他集群（通过GCP控制台创建）可以正确访问同一映像，因此我的想法是，通过API创建的集群（在本例中为通过GitLab）与通过GCP控制台创建的集群之间存在一些差异。

我希望过去有人遇到过这种情况-或可以解释可能导致问题的服务帐户等方面的差异。

我将尝试创建一个服务帐户并手动为其授予Project Viewer角色，以查看是否可以解决问题。

更新：手动配置的服务帐户无法解决问题。

注意：我试图将映像拉入群集，而不是拉入在群集上运行的GitLab Runner中。就是 我希望在我的GitLab基础架构旁边运行单独的服务/部署。

似乎在 DynamoDB 中处理 Sort Key Date 对象（ISO 8061 格式）的共识是使用 STRING 键类型，其中查询案例将使用 BETWEEN 比较来查找两个日期（也是 ISO 8061）之间的结果，请参阅答案：

1. 是否可以将日期时间保存到 DynamoDB？

我的问题是确实的DynamoDB字符串比较“之间”，使上述功能的机制ALSO可以查询两个Date对象缝合在一起（例如：2018-05-01-2018-05-10）作为一个单一的排序密钥其中，第一个缝合日期总是在第二个缝合日期之前。

经过初步测试，答案似乎是肯定的，只要您的 BETWEEN 查询也有两个串联日期，这应该是可能的。

我希望有人可以帮助我弄清楚这是否可以安全/稳定地部署。

在我们进入背景之前，我想我会在这里发布我的测试用例，以明确我在问什么。

给定排序键：2018-05-01-2018-05-25

1. 查询 BETWEEN 2018-05-01-2018-05-20 和 2018-05-01-2018-05-26（RETURNS 项）
2. 在 2018-05-01-2018-05-20 和 2018-05-01-2018-05-24 之间查询（未找到数据）
3. 查询 BETWEEN 2018-05-01-2018-05-20 和 2018-05-01-2018-05-25（RETURNS 项）
4. 在 2018-05-02-2018-05-20 和 2018-05-02-2018-05-26 之间查询（未找到数据）

背景

我正在构建一个可查询的 DynamoDB 航班组合表，我希望查询可以检查出发航班日期是否在某个日期之后，以及返回航班是否在某个日期之前。

基本上我的理解是，由于数字从左到右（年-月-日）级联的方式，DynamoDB 中 ISO 8061 日期的 BETWEEN 查询可以工作。如果是这种情况，那么将两个日期连接成一个排序键应该是安全的（在我的情况下）。

排序键值的表示将是...

• 出发日期1-返回日期2
• 年月日年月日

我正在预先检查数据，以便可以假设离港航班（第一个连续日期）总是在返回航班（第二个连续日期）之前，如果它在我们的表中，因此给出一个 BETWEEN 操作，我的假设是这应该成为可能。

我会在更多测试后回帖，但我希望有人对 DynamoDB BETWEEN Query 函数在这种情况下的确切工作方式（以及原因）有更多经验。

因此，这似乎很容易，但一直很棘手。显然，无服务器与webpack捆绑在一起，然后上传到S3，然后再与Cloud Formation一起部署。

这里的问题是webpack的节点__dirname有一些问题，您可以在此处阅读：https : //github.com/webpack/webpack/issues/1599

基本上，这意味着您甚至需要考虑在使用__dirname来获取绝对路径之前（在之后target: node,），将以下内容添加到webpack配置中：

  // assume target: 'node', is here

  node: {
    __dirname: false,
  },:

所以。大。我的问题是：

对于基于标准入门工具包的具有多个功能的无服务器项目，基本存储库中给定功能的根目录是什么？

我将上述代码添加到了webpack配置中，并且__dirname现在又可以使用了，但是我仍然无法找到存储在仓库中的文件。

仓库如下所示：

repo-root
——— src
——— ——— someFunction
——— ——— ——— some-sub-directory
——— ——— ——— ——— targetfile.json

为了命中targetfile.json，我应在'__dirname'后面附加什么？

使用 Ghost 博客 paths.yaml 文件，可以使用集合块来创建由某些标签和/或其他数据组成的自定义集合。您还可以告诉此集合使用自定义主题模板，请参阅：

\n
1. https://docs.ghost.org/tutorials/creating-content-collections/
\n
2. https://docs.ghost.org/concepts/routing/#content-struct
\n

例如：

collections:\n  /example/:\n    permalink: /example/{slug}/\n    controller: channel\n    filter: tag:example-tag\n    template:\n      - example\n

以上所有作品和我的收藏都正确使用了我的新作品example主题文件。

问题在于，与标签页不同（对于example-tag）不同，我的新自定义集合没有易于记录的方式来处理标题等。

它不会从用于构建集合的标签中提取标题/元描述（这对于从单个标签构建的集合来说非常有用）。为了解决这个问题，我尝试了一些{{#has}}语句，但是\xc2\xa0我无法弄清楚自定义路由适合什么上下文。

\n

在上面的routes.yaml示例中，自定义集合的标题最终为“我的站点名称（第1页）”\xe2\x80\x94\xc2\xa0，并且没有元描述。

\n

此问题还扩展到开放图谱数据，该数据列出了相同的标题，但没有自定义集合的描述。

我的猜测是，可能可以使用附加到 paths.yaml 文件的数据属性来实现此目的（请参阅： https: //docs.ghost.org/concepts/routing/#data），但我还没有找到目前为止的解决方案。

\n

虽然我最初尝试在谷歌上搜索解决方案却一无所获，但这是我见过的对该问题的最佳参考：

\n

\n
1. https://forum.ghost.org/t/dynamic-routing-page-post-data-context-in-default-hbs-nested-navigation-on-custom-collections/4204
\n
2. https://github.com/TryGhost/Ghost/issues/10082
\n

我正在我创建的docker容器中运行基础Vue.js Webpack模板(https://github.com/vuejs-templates/webpack/)的webpack/webpack-dev-server部分.容器还包含vue CLI以创建新项目(如果需要,可以在此处获取我的容器:https://hub.docker.com/r/ncevl/webpack-vue/).

从webpack-simple模板移动到此模板后,热重新加载不起作用.

一切都在使用Webpack-Simple模板,您可以在这里克隆/查看:https://github.com/vuejs-templates/webpack-simple

我可以使用以下webpack-development-server启动命令运行简单模板(使用热重载按预期工作):

webpack-dev-server --hot --inline --progress --host 0.0.0.0 --watch-poll

也就是说,webpack模板的完整(非简单)版本似乎没有使用webpack-dev-server启动命令,而是使用build/dev-server.js(https:// github)中引用的其他中间件. com/vuejs-templates/webpack/blob/master/template/build/dev-server.js)和webpack dev config.

由于--watch-poll是让WDS热重载功能在上一个项目中的docker容器中工作的关键,我的想法是我需要做一些与webpack-hot-middleware类似的东西,但我看不到他们的文档中的任何内容(在这里:https://github.com/glenjamin/webpack-hot-middleware)都谈到了改为基于轮询的方法.

我不是100%肯定轮询标志会起作用,因为我可以看到容器在我做出更改时重新编译我的源代码.如果我手动刷新,我也可以在浏览器中看到更改.

如果我在chrome dev工具中检查浏览器中的页面,然后转到network/XHR我可以看到浏览器确实从webpack-dev-server接收信息,但在视觉上它不会更新.

给出上面的假设我认为websockets(或者我认为使用的socket.io)正在浏览器和WDS之间进行通信,所以这可能是某种浏览器缓存问题？

我检查了我的控制台,发现这看起来像一个标题问题:

作为参考,该图像的文本错误(为了让任何有相同问题的人更容易找到这篇文章)是:

EventSource无法加载http:// __ webpack_hmr /.请求的资源上不存在"Access-Control-Allow-Origin"标头.因此不允许来源' http://0.0.0.0:8080 '访问.

使用webpack-simple Vue.js模板时,Hot-Reload/Hot Module Reload再次使用这个相同的容器设置.

我想知道是否有人遇到类似的事情,或者对如何添加轮询选项有任何想法.我想我的替代方案是回滚到更基本的webpack配置并重建那部分东西以使用传统的webpack-dev-server/webpack配置但是给出上述我不确定是否会解决它.

在会计系统内对存款进行核对，从运行 Shopify Payments（或其他方式）的 Shopify 商店进入 Shopify 用户的银行帐户，这似乎是人们经常根据数字偶然发现 \xe2\x80\x94 的事情之一有关 Shopify 支持社区论坛上的主题的请求，例如： https: //community.shopify.com/c/Shopify-APIs-SDKs/Fees-charged-by-Shopify-via-API/mp/265261 /

问题（对于会计）是 Shopify Payments在将交易余额存入店主的账户之前删除了费用金额（有关费用的完整列表，请参阅：https: //www.shopify.com/pricing ）银行账户。

Shopify 费用通常如下所示：2.6% of transaction value + $0.30

根据上述内容计算应收取的费用非常简单（对费用表进行硬编码），直到这些费用在未来某个时候发生变化。

这对集成有何影响？

对于许多可用的简单集成，这会导致打入银行帐户的发票金额与我们根据通过 Shopify 轻松检索的 Shopify 发票金额“预期”打入银行帐户的金额之间存在差异。的 API 由许多此类解决方案提供。

这种差异意味着基于会计的用户有必要手动推断哪个 Shopify 发票与哪个传入银行存款 \xe2\x80\x94\xc2\xa0 相关联，然后手动添加一个负行项目来计算差额/余额图书。

\n

这是几个不同的会计系统/软件供应商（特别是 Xero 和 Quickbooks）在被问及他们的客户如何解决上述问题时提出的建议方法。

\n

我知道有一些解决方案试图解决上述所有问题（取得了不同程度的成功），但由于我目前的情况涉及大量的配套工作，这些解决方案都无法充分解决我们业务所需的其他功能。

\n

我们需要能够找到费用（或者自己计算）并将这些费用添加到发票中，以便我们的会计系统期望正确的资金金额打入我们的银行帐户 \xe2\x80\x94 因此问题：如何我们可以检索当前帐户的“Shopify Payments”费用/费率吗？

\n

理想情况下，我希望避免对这些信息进行硬编码，因为 Shopify 可能会更改费用（可能只发出少量通知），这意味着到那时我们的集成就会中断。最好能够通过 API 请求检索给定帐户的费用表，从而避免费用发生变化时出现问题。

我有多个客户也面临同样的问题 \xe2\x80\x94\xc2\xa0so 我认为值得检查一下是否有人遇到/解决了问题，并讨论我当前的解决方案

Shopify 说什么？

我们正在Azure AKS上运行几个k8s群集。该服务（幽灵博客）位于Nginx入口后面，并由Letsencrypt提供的证书进行保护。所有这些都很好，但是重定向行为是我遇到的麻烦。

Ingress可以正确地从http://whatever.com重定向到 https://whatever.com-问题是它使用308重定向来做到这一点，只要用户在网站上共享页面，该重定向就会剥离所有帖子/页面元。

此问题导致在大多数社交媒体资源上共享网站任何页面的用户都收到“预览链接”（页面标题和页面元预览不起作用，而是由“ 308永久重定向”文本代替）看起来像这样：

从这里的ingress-nginx文档中，我可以看到这是预期的行为（即308重定向），我认为这不是在社交共享服务尝试创建页面预览时与社交共享服务的交互。

尽管默认情况下Facebook（或twitter等）直接指向https网站可以解决此问题，但我目前无法强制这些网站将要用于创建预览的内容转向https。

设置永久重定向代码

我还看到，看来我应该能够将重定向代码设置为所需的格式（我相信301重定向将使Facebook等人正确提取帖子/网页摘要元），有关该文档在这里。

问题是当我按指定添加重定向代码注释时：

nginx.ingress.kubernetes.io/permanent-redirect-code: "301"

尽管能够（从我的kubectl代理中）看到重定向代码注释正确应用，但我仍然在资源上获得308重定向。作为参考，我在Ingress上的注释的完整列表如下所示：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ghost-ingress
  annotations:
    kubernetes.io/tls-acme: "true"
    nginx.ingress.kubernetes.io/permanent-redirect-code: "301"

重申-我的问题是；通过自定义错误代码（在我的情况下为301）强制重定向到https的正确方法是什么？

致力于 Docker 化一个 Nodejs 应用程序，我正在尝试对其进行设置，以便它能够从非标准端口进行响应，从而避免已经运行本地 Redis 容器或服务的团队成员发生潜在冲突。

Redis通常运行在6379上（无论是否有docker）。我希望它在 6380 上监听。即使我在 docker-compose 文件中没有它，我也想用 RethinkDB 做同样的事情。

我不想为 Redis 或 RethinkDB 创建新的 Dockerfile。

这是我的 Docker-Compose 文件。

  nodejsapp:
    image: some-node-container
    container_name: nodejsapp
    ports:
      - "5200:5200" #first number must match CHEAPOTLE_PORT env variable for the cheapotle service
    depends_on:
      - redis
      - rethinkdb
    volumes:
      - ./:/app
    environment:
      - NODEJSAPP_PORT=5200 #must match first port number for cheapotle service above.
      - REDIS_PORT=6380 #must match first number in redis service ->ports below.
      - RETHINKDB_PORT=28016 #must match first number in …