<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Ops on Murat Useinov</title>
    <link>https://useinov.com/tags/ops/</link>
    <description>Recent content in Ops on Murat Useinov</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 07 Aug 2019 18:05:00 +0300</lastBuildDate>
    <atom:link href="https://useinov.com/tags/ops/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>200 OK is not health</title>
      <link>https://useinov.com/posts/2019/kubernetes-probes-php/</link>
      <pubDate>Wed, 07 Aug 2019 18:05:00 +0300</pubDate>
      <guid>https://useinov.com/posts/2019/kubernetes-probes-php/</guid>
      <description>&lt;p&gt;Route &lt;code&gt;/health&lt;/code&gt;, returns &lt;code&gt;ok&lt;/code&gt;, everyone happy. That is the first version of every health endpoint on the project we are moving to Kubernetes. Then somebody pastes the same path into &lt;code&gt;livenessProbe&lt;/code&gt; and &lt;code&gt;readinessProbe&lt;/code&gt;, and a thirty second database hiccup becomes a long evening.&lt;/p&gt;
&lt;p&gt;The two probes ask different questions.&lt;/p&gt;
&lt;p&gt;Readiness asks: should this pod get traffic right now. Here it is correct to check dependencies. Database unreachable, cache cold, migrations still running: answer no. Kubernetes takes the pod out of the Service, traffic goes to the others, the pod returns when the world improves. Failing readiness is cheap and reversible. A polite &amp;ldquo;not now&amp;rdquo;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>What Redis does when memory ends</title>
      <link>https://useinov.com/posts/2019/redis-maxmemory/</link>
      <pubDate>Tue, 02 Apr 2019 15:10:00 +0300</pubDate>
      <guid>https://useinov.com/posts/2019/redis-maxmemory/</guid>
      <description>&lt;p&gt;Users logged out at random. Not all, not always. Only sometimes, only in the afternoon. Afternoon is when traffic peaks. Traffic peaks fill the cache. The cache lived in the same Redis as the sessions, the instance hit &lt;code&gt;maxmemory&lt;/code&gt;, and the eviction policy was &lt;code&gt;allkeys-lru&lt;/code&gt;. Redis did exactly what we asked: threw away the least recently used keys, and some of them were sessions of people who went for lunch.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
