albatross0の投稿 - Crieit

LVS のセッション数上限についてメモ

2020-10-14T22:59:43+09:00

Qrunch から引っ越し

conntrack については nf_conntrack_max の話題を時々聞くが、
ipvs のセッション数はリミットを気にしなくていいんだっけ。

ちょうど手元にあった kernel-ml-4.13.5-1.el7.elrepo.nosrc.rpm のソースで確認

conntrack

そもそも nf_conntrack_max はどうなっているのか確認

net/netfilter/nf_conntrack_core.c

static struct nf_conn *
__nf_conntrack_alloc(struct net *net,
             const struct nf_conntrack_zone *zone,
             const struct nf_conntrack_tuple *orig,
             const struct nf_conntrack_tuple *repl,
             gfp_t gfp, u32 hash)
{
    struct nf_conn *ct;

    /* We don't want any race condition at early drop stage */
    atomic_inc(&net->ct.count);

    if (nf_conntrack_max &&
        unlikely(atomic_read(&net->ct.count) > nf_conntrack_max)) {
        if (!early_drop(net, hash)) {
            if (!conntrack_gc_work.early_drop)
                conntrack_gc_work.early_drop = true;
            atomic_dec(&net->ct.count);
            net_warn_ratelimited("nf_conntrack: table full, dropping packet\n");
            return ERR_PTR(-ENOMEM);
        }
    }

    /*
     * Do not use kmem_cache_zalloc(), as this cache uses
     * SLAB_TYPESAFE_BY_RCU.
     */
    ct = kmem_cache_alloc(nf_conntrack_cachep, gfp);
    if (ct == NULL)
        goto out;

対象の netns の conntrack の数が nf_conntrack_max より多ければログを出して抜ける。
nf_conntrack_max 以下の場合はその次の処理 kmem_cache_alloc() で nf_conn 構造体の領域が割り当てられるようだ。

ipvs

続いて ipvs の場合はどうか確認

net/netfilter/ipvs/ip_vs_conn.c

truct ip_vs_conn *
ip_vs_conn_new(const struct ip_vs_conn_param *p, int dest_af,
           const union nf_inet_addr *daddr, __be16 dport, unsigned int flags,
           struct ip_vs_dest *dest, __u32 fwmark)
{
    struct ip_vs_conn *cp;
    struct netns_ipvs *ipvs = p->ipvs;
    struct ip_vs_proto_data *pd = ip_vs_proto_data_get(p->ipvs,
                               p->protocol);

    cp = kmem_cache_alloc(ip_vs_conn_cachep, GFP_ATOMIC);
    if (cp == NULL) {
        IP_VS_ERR_RL("%s(): no memory\n", __func__);
        return NULL;
    }

ip_vs_conn_new() にそれらしきものは無い。呼び出し元を見ても、特に何かのパラメータによる制限は無さそう。

スラブアロケータは全然分かってないけど、inode のキャッシュでめっちゃメモリ食われてたという話を聞くし、メモリが空いている限り使えるのだろう。

そういえば inode のキャッシュって drop_caches で消せるけど、これは大丈夫なんだろうか。多分何か識別するものがあるはずなので xfs の inode あたりを確認してみる。

fs/xfs/xfs_super.c

    xfs_inode_zone =
        kmem_zone_init_flags(sizeof(xfs_inode_t), "xfs_inode",
            KM_ZONE_HWALIGN | KM_ZONE_RECLAIM | KM_ZONE_SPREAD |
            KM_ZONE_ACCOUNT, xfs_fs_inode_init_once);

fs/xfs/kmem.h

#define KM_ZONE_RECLAIM SLAB_RECLAIM_ACCOUNT

/* 勝手に省略 */

static inline kmem_zone_t *
kmem_zone_init_flags(int size, char *zone_name, unsigned long flags,
             void (*construct)(void *))
{
    return kmem_cache_create(zone_name, size, 0, flags, construct);
}

include/linux/slab.h

/* The following flags affect the page allocator grouping pages by mobility */
#define SLAB_RECLAIM_ACCOUNT    0x00020000UL        /* Objects are reclaimable */

kmem_cache_create() する時に SLAB_RECLAIM_ACCOUNT のフラグ渡しているようだ。

ipvs で kmem_cache_create() しているところはこのフラグが無かったので大丈夫なのだろう

net/netfilter/ipvs/ip_vs_conn.c

int __init ip_vs_conn_init(void)
{
    int idx;

    /* Compute size and mask */
    ip_vs_conn_tab_size = 1 << ip_vs_conn_tab_bits;
    ip_vs_conn_tab_mask = ip_vs_conn_tab_size - 1;

    /*
     * Allocate the connection hash table and initialize its list heads
     */
    ip_vs_conn_tab = vmalloc(ip_vs_conn_tab_size * sizeof(*ip_vs_conn_tab));
    if (!ip_vs_conn_tab)
        return -ENOMEM;

    /* Allocate ip_vs_conn slab cache */
    ip_vs_conn_cachep = kmem_cache_create("ip_vs_conn",
                          sizeof(struct ip_vs_conn), 0,
                          SLAB_HWCACHE_ALIGN, NULL);
    if (!ip_vs_conn_cachep) {
        vfree(ip_vs_conn_tab);
        return -ENOMEM;
    }

サービス毎のセッション数制限

nf_conntrack_max のような全体の (network namespace 毎の) 制限値は無さそうだが、ググったらサービス毎に上限を設定できるらしい。

ipvsadm -h から抜粋すると以下の部分のようだ。

  --u-threshold  -x uthreshold        upper threshold of connections
  --l-threshold  -y lthreshold        lower threshold of connections

lower threshold はどういう時に使うのかよく分からない。気にしないでおく。
upper threshold もそうだが、明示的に指定しなければ制限しないようだ。
ipvsadm -ln --thresholds した時に Uthreshold が 0 になっていれば制限されていない。

ちょっと試してみたところ、すべての real server が upper threshold に達した状態で新規セッションの通信がきた場合は ICMP Port Unreachable を返すようだ。

それはいいのだが、セッションの数として inactive なセッションもカウントされているので、セッションを使い続けるのではなく接続・切断が頻繁に起こる場合などでは TIME_WAIT が多くなってしまい、制限方法として採用しづらい。

net/netfilter/ipvs/ip_vs_conn.c

static inline int ip_vs_dest_totalconns(struct ip_vs_dest *dest)
{
    return atomic_read(&dest->activeconns)
        + atomic_read(&dest->inactconns);
}

/*
 *  Bind a connection entry with a virtual service destination
 *  Called just after a new connection entry is created.
 */
static inline void
ip_vs_bind_dest(struct ip_vs_conn *cp, struct ip_vs_dest *dest)
{
/* 勝手に省略 */
    if (dest->u_threshold != 0 &&
        ip_vs_dest_totalconns(dest) >= dest->u_threshold)
        dest->flags |= IP_VS_DEST_F_OVERLOAD;
}

結論

lower/upper threshold を使っていなければ、ipvs セッション上限は気にしない。メモリの量は気にする。

GKE を upgrade したら network plugin が死んだので対応した作業記録

2020-10-14T22:58:44+09:00

Qrunch から引っ越し

※ GKE のネガキャンではありません。むしろ好きでちゃんと運用したいからこそ残しているものです。

軽い気持ちで GKE を 1.11.2-gke.18 から 1.11.3-gke.18 に upgrade した。

そして何気なく Deployment を作ったが Pod が起動しない。
kubectl describe pod で見るとおかしな event が記録されているのが分かった。

Events:
  Type     Reason                  Age               From                                            Message
  ----     ------                  ----              ----                                            -------
  Normal   Scheduled               3m                default-scheduler                               Successfully assigned xyz/hoge-5b4db95bf5-krmjc to gke-gke01-preemptible01-e5cc132c-77fz
  Warning  FailedCreatePodSandBox  3m                kubelet, gke-gke01-preemptible01-e5cc132c-77fz  Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "af7579fb0a4ad73cfaeb083ef47de36b7f84aed7f160685384354ed0d8512339" network for pod "hoge-5b4db95bf5-krmjc": NetworkPlugin cni failed to set up pod "hoge-5b4db95bf5-krmjc_xyz" network: stat /var/lib/calico/nodename: no such file or directory: check that the calico/node container is running and has mounted /var/lib/calico/
  Warning  FailedCreatePodSandBox  3m                kubelet, gke-gke01-preemptible01-e5cc132c-77fz  Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "56c9b914c9f3c940c8d5479807820814e43f6716a263ca5c9a1bf53cef6ae252" network for pod "hoge-5b4db95bf5-krmjc": NetworkPlugin cni failed to set up pod "hoge-5b4db95bf5-krmjc_xyz" network: stat /var/lib/calico/nodename: no such file or directory: check that the calico/node container is running and has mounted /var/lib/calico/
  Warning  FailedCreatePodSandBox  3m                kubelet, gke-gke01-preemptible01-e5cc132c-77fz  Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "10bdc42cc20617283e18f67a4e4d171eecb4182dd0e9f7114465c4047e5f3c12" network for pod "hoge-5b4db95bf5-krmjc": NetworkPlugin cni failed to set up pod "hoge-5b4db95bf5-krmjc_xyz" network: stat /var/lib/calico/nodename: no such file or directory: check that the calico/node container is running and has mounted /var/lib/calico/

このクラスタは NetworkPolicy を有効にしているため、Calico が動作している。
kube-system namespace の Pod を見てみると、何やらひどいことが起きているようだ。

$ kubectl -n kube-system get pod | grep -E '^NAME|calico'
NAME                                                  READY     STATUS             RESTARTS   AGE
calico-node-974fs                                     1/2       CrashLoopBackOff   9          24m
calico-node-fx464                                     1/2       CrashLoopBackOff   9          24m
calico-node-kzhsr                                     1/2       CrashLoopBackOff   9          24m
calico-node-q4ktd                                     1/2       CrashLoopBackOff   9          24m
calico-node-qwqsx                                     1/2       CrashLoopBackOff   9          24m
calico-node-vertical-autoscaler-547d98499d-l7rd2      1/1       Running            0          6h
calico-typha-5977794b76-dmxjr                         0/1       CrashLoopBackOff   9          24m
calico-typha-horizontal-autoscaler-5ff7f558cc-2ksbc   1/1       Running            0          19h
calico-typha-vertical-autoscaler-5d4bf57df5-hp8r6     1/1       Running            0          6h

network plugin が動作しなくなっているため、既存 Pod はまだ生き延びられるが、新規 Pod が起動しない状態になっているようだ。

calico-node の DaemonSet を YAML で出力して中身をみると、v2.6.11 だったはずの calico のイメージが v3.2.4 に上がっていた。
(バージョンを確認したのは、別件で GKE の問い合わせをしていて Calico のバージョンが変わりそうな気配を感じていたため)

別途 NetworkPolicy を有効にした新規クラスタを作成してみて、そちらでは問題無く動作することを確認。

問題が起きている方のクラスタで calico-node の Pod のログを見ると以下のようになっていた。

2018-12-05 05:16:41.622 [INFO][8] startup.go 252: Early log level set to info
2018-12-05 05:16:41.623 [INFO][8] startup.go 268: Using NODENAME environment for node name
2018-12-05 05:16:41.623 [INFO][8] startup.go 280: Determined node name: gke-gke00-preemptible01-df3d5d39-m2h6
2018-12-05 05:16:41.624 [INFO][8] startup.go 303: Checking datastore connection
2018-12-05 05:16:41.638 [INFO][8] startup.go 327: Datastore connection verified
2018-12-05 05:16:41.638 [INFO][8] startup.go 100: Datastore is ready
2018-12-05 05:16:41.651 [INFO][8] startup.go 1052: Running migration
2018-12-05 05:16:41.651 [INFO][8] migrate.go 866: Querying current v1 snapshot and converting to v3
2018-12-05 05:16:41.651 [INFO][8] migrate.go 875: handling FelixConfiguration (global) resource
2018-12-05 05:16:41.658 [INFO][8] migrate.go 875: handling ClusterInformation (global) resource
2018-12-05 05:16:41.658 [INFO][8] migrate.go 875: skipping FelixConfiguration (per-node) resources - not supported
2018-12-05 05:16:41.658 [INFO][8] migrate.go 875: handling BGPConfiguration (global) resource
2018-12-05 05:16:41.658 [INFO][8] migrate.go 600: Converting BGP config -> BGPConfiguration(default)
2018-12-05 05:16:41.677 [INFO][8] migrate.go 875: skipping Node resources - these do not need migrating
2018-12-05 05:16:41.677 [INFO][8] migrate.go 875: skipping BGPPeer (global) resources - these do not need migrating
2018-12-05 05:16:41.677 [INFO][8] migrate.go 875: handling BGPPeer (node) resources
2018-12-05 05:16:41.687 [INFO][8] migrate.go 875: skipping HostEndpoint resources - not supported
2018-12-05 05:16:41.687 [INFO][8] migrate.go 875: skipping IPPool resources - these do not need migrating
2018-12-05 05:16:41.687 [INFO][8] migrate.go 875: skipping GlobalNetworkPolicy resources - these do not need migrating
2018-12-05 05:16:41.687 [INFO][8] migrate.go 875: skipping Profile resources - these do not need migrating
2018-12-05 05:16:41.688 [INFO][8] migrate.go 875: skipping WorkloadEndpoint resources - these do not need migrating
2018-12-05 05:16:41.688 [INFO][8] migrate.go 875: data converted successfully
2018-12-05 05:16:41.688 [INFO][8] migrate.go 866: Storing v3 data
2018-12-05 05:16:41.688 [INFO][8] migrate.go 875: Storing resources in v3 format
2018-12-05 05:16:41.752 [INFO][8] migrate.go 1151: Failed to create resource Key=BGPConfiguration(default) error=resource does not exist: BGPConfiguration(default) with error: the server could not find the requested resource (post BGPConfigurations.crd.projectcalico.org)
2018-12-05 05:16:41.753 [ERROR][8] migrate.go 884: Unable to store the v3 resources
2018-12-05 05:16:41.753 [INFO][8] migrate.go 875: cause: resource does not exist: BGPConfiguration(default) with error: the server could not find the requested resource (post BGPConfigurations.crd.projectcalico.org)
2018-12-05 05:16:41.753 [ERROR][8] startup.go 107: Unable to ensure datastore is migrated. error=Migration failed: error storing converted data: resource does not exist: BGPConfiguration(default) with error: the server could not find the requested resource (post BGPConfigurations.crd.projectcalico.org)
2018-12-05 05:16:41.753 [WARNING][8] startup.go 1066: Terminating

新規構築したクラスタの calico-node の Pod のログと見比べると migrate.go の行が存在しない。
2018-12-05 05:16:41.651 [INFO][8] startup.go 1052: Running migration という部分が鍵と思われる。

startup.go は projectcalico/node を見れば良さそうだが、
migrate.go は projectcalico/libcalico-go にあるようだ。
libcalico-go のバージョンはどれを使っているのか分からないが、ログから BGPConfiguration を作れていない様子がうかがえる。

Kubernetes における Calico は CustomResourceDefinition として設定を管理しているらしいので、crd の定義を調べる

$ kubectl get crd
NAME                                          AGE
backendconfigs.cloud.google.com               22h
clusterinformations.crd.projectcalico.org     22h
felixconfigurations.crd.projectcalico.org     22h
globalbgpconfigs.crd.projectcalico.org        22h
globalfelixconfigs.crd.projectcalico.org      22h
globalnetworkpolicies.crd.projectcalico.org   22h
globalnetworksets.crd.projectcalico.org       22h
hostendpoints.crd.projectcalico.org           22h
ippools.crd.projectcalico.org                 22h
networkpolicies.crd.projectcalico.org         22h
scalingpolicies.scalingpolicy.kope.io         22h

ログには
the server could not find the requested resource (post BGPConfigurations.crd.projectcalico.org)
と出ていて、実際に bgpconfigurations.crd.projectcalico.org は存在しない。

とりあえず手動で CRD を追加してみたい。
内容が分からないので適当にググると https://github.com/projectcalico/libcalico-go/blob/master/test/crds.yaml が見つかった。

元の CRD を残しておきつつ、この crds.yaml を適用してみる。

$ kubectl get crd -o yaml > crd-backup.yaml
$ curl -LO https://raw.githubusercontent.com/projectcalico/libcalico-go/master/test/crds.yaml
$ kubectl apply -f crds.yaml
customresourcedefinition.apiextensions.k8s.io "globalfelixconfigs.crd.projectcalico.org" configured
customresourcedefinition.apiextensions.k8s.io "globalbgpconfigs.crd.projectcalico.org" configured
customresourcedefinition.apiextensions.k8s.io "ippools.crd.projectcalico.org" configured
customresourcedefinition.apiextensions.k8s.io "bgppeers.crd.projectcalico.org" created
customresourcedefinition.apiextensions.k8s.io "globalnetworkpolicies.crd.projectcalico.org" configured
customresourcedefinition.apiextensions.k8s.io "hostendpoints.crd.projectcalico.org" configured
customresourcedefinition.apiextensions.k8s.io "felixconfigurations.crd.projectcalico.org" configured
customresourcedefinition.apiextensions.k8s.io "bgpconfigurations.crd.projectcalico.org" created
customresourcedefinition.apiextensions.k8s.io "clusterinformations.crd.projectcalico.org" configured
customresourcedefinition.apiextensions.k8s.io "networkpolicies.crd.projectcalico.org" configured
customresourcedefinition.apiextensions.k8s.io "globalnetworksets.crd.projectcalico.org" configured

bgppeers.crd.projectcalico.org と bgpconfigurations.crd.projectcalico.org が新規作成されたようだ。
CRD が作られたので、CrashLoopBackOff になっていた calico-node や calico-typha の Pod を消して再作成させる。

$ kubectl -n kube-system get pod -l k8s-app=calico-node
$ kubectl -n kube-system delete pod -l k8s-app=calico-node
$ kubectl -n kube-system get pod -l k8s-app=calico-typha
$ kubectl -n kube-system delete pod -l k8s-app=calico-typha

これでしばらく放置しておくと、calico-node や calico-typha の Pod が起動し、他の Pod も起動するようになった。

migrate.go が成功した部分のログは以下のようなものだった。

2018-12-05 05:45:51.223 [INFO][8] startup.go 1052: Running migration
2018-12-05 05:45:51.223 [INFO][8] migrate.go 866: Querying current v1 snapshot and converting to v3
2018-12-05 05:45:51.223 [INFO][8] migrate.go 875: handling FelixConfiguration (global) resource
2018-12-05 05:45:51.232 [INFO][8] migrate.go 875: handling ClusterInformation (global) resource
2018-12-05 05:45:51.232 [INFO][8] migrate.go 875: skipping FelixConfiguration (per-node) resources - not supported
2018-12-05 05:45:51.232 [INFO][8] migrate.go 875: handling BGPConfiguration (global) resource
2018-12-05 05:45:51.232 [INFO][8] migrate.go 600: Converting BGP config -> BGPConfiguration(default)
2018-12-05 05:45:51.245 [INFO][8] migrate.go 875: skipping Node resources - these do not need migrating
2018-12-05 05:45:51.245 [INFO][8] migrate.go 875: skipping BGPPeer (global) resources - these do not need migrating
2018-12-05 05:45:51.245 [INFO][8] migrate.go 875: handling BGPPeer (node) resources
2018-12-05 05:45:51.255 [INFO][8] migrate.go 875: skipping HostEndpoint resources - not supported
2018-12-05 05:45:51.255 [INFO][8] migrate.go 875: skipping IPPool resources - these do not need migrating
2018-12-05 05:45:51.255 [INFO][8] migrate.go 875: skipping GlobalNetworkPolicy resources - these do not need migrating
2018-12-05 05:45:51.255 [INFO][8] migrate.go 875: skipping Profile resources - these do not need migrating
2018-12-05 05:45:51.255 [INFO][8] migrate.go 875: skipping WorkloadEndpoint resources - these do not need migrating
2018-12-05 05:45:51.255 [INFO][8] migrate.go 875: data converted successfully
2018-12-05 05:45:51.255 [INFO][8] migrate.go 866: Storing v3 data
2018-12-05 05:45:51.255 [INFO][8] migrate.go 875: Storing resources in v3 format
2018-12-05 05:45:51.324 [INFO][8] migrate.go 875: success: resources stored in v3 datastore
2018-12-05 05:45:51.324 [INFO][8] migrate.go 866: Migrating IPAM data
2018-12-05 05:45:51.324 [INFO][8] migrate.go 875: no data to migrate - not supported
2018-12-05 05:45:51.324 [INFO][8] migrate.go 866: Data migration from v1 to v3 successful
2018-12-05 05:45:51.324 [INFO][8] migrate.go 875: check the output for details of the migrated resources
2018-12-05 05:45:51.324 [INFO][8] migrate.go 875: continue by upgrading your calico/node versions to Calico v3.x
2018-12-05 05:45:51.324 [INFO][8] startup.go 1056: Migration successful

本来は GKE 側で修正されることではないかと思うが、どうなるのだろう。

後日確認・追記 (12/14)

GKE の Release Notes の Known Issues (抜粋):
> Users upgrading to GKE 1.11.3 on clusters that use Calico network policies may experience failures due to a problem recreating the BGPConfigurations.crd.projectcalico.org resource. This problem does not affect newly-created clusters. This is expected to be fixed in the coming weeks.
>
> To work around this problem, you can create the BGPConfigurations.crd.projectcalico.org resource manually:
Google の Issue Tracker: URGENT: after upgrading master nodes to 1.11.3 calico stopped working
Calico の Issue: #2324
Kubernetes の PullRequest: #71868, #71682
- release-1.11 ブランチへのマージ: #71918
- release-1.12 ブランチへのマージ: #71882
- release-1.13 ブランチへのマージ: #71883
- v1.13.1 のリリースで修正済み Changelog
  > Include CRD for BGPConfigurations, needed for calico 2.x to 3.x upgrade. (#71868, @satyasm)
- 他のバージョンも次リリースされた時に修正されているはず。GKE もどこかで修正されることだろう。

GKE の kube-proxy が drain されない理由

2020-10-14T22:57:52+09:00

Qrunch から引っ越し

kubectl drain した時、テストで作った ownerReference の無い Pod がいたために怒られた。
(これらの Pod は --force オプションで削除させることができる)

ふと kube-proxy のことを思い出し、気になって調べた。

GKE だと kube-proxy は /etc/kubernetes/manifests から起動されていて ownerReference は無いはずなのだが、どうやって drain を回避しているのだろうか。

ファイルの manifest から起動しているのでそもそも API server 経由で実際の Pod 削除はできないのだが、Pod の定義だけ (一時的に) 削除することはあり得るのでは？

pkg/kubectl/cmd/drain.go を読むと分かる。

RunDrain()
  deleteOrEvictPodsSimple()
    getPodsForDeletion()
    deleteOrEvictPods()

kubectl drain コマンドにはいくつかのフィルタ条件があり、それらが適用されて残った Pod が
deleteOrEvictPods() に渡される。

各フィルタは getPodsForDeletion() の中で適用される。

// getPodsForDeletion receives resource info for a node, and returns all the pods from the given node that we
// are planning on deleting. If there are any pods preventing us from deleting, we return that list in an error.
func (o *DrainOptions) getPodsForDeletion(nodeInfo *resource.Info) (pods []corev1.Pod, err error) {
    labelSelector, err := labels.Parse(o.PodSelector)
    if err != nil {
        return pods, err
    }

    podList, err := o.client.CoreV1().Pods(metav1.NamespaceAll).List(metav1.ListOptions{
        LabelSelector: labelSelector.String(),
        FieldSelector: fields.SelectorFromSet(fields.Set{"spec.nodeName": nodeInfo.Name}).String()})
    if err != nil {
        return pods, err
    }

    ws := podStatuses{}
    fs := podStatuses{}

    for _, pod := range podList.Items {
        podOk := true
        for _, filt := range []podFilter{o.daemonsetFilter, mirrorPodFilter, o.localStorageFilter, o.unreplicatedFilter} {
            filterOk, w, f := filt(pod)

            podOk = podOk && filterOk

-l, --selector='' は drain 対象の Node をフィルタするもので、Pod に作用するものではない。
--pod-selector='' で drain で処理する Pod をフィルタする。
例えば、特定のラベルを持つ Pod を evict/delete 対象から外すには --pod-selector='key!=value' をつける
--ignore-daemonsets は DaemonSet から作成された Pod を除外する。(daemonsetFilter)
--delete-local-data は emptyDir ボリュームを持つ Pod を除外する。(localStorageFilter)

ownerRefernece の有無は unreplicatedFilter で判定されるが、kube-proxy が除外されるのは mirrorPodFilter だった。

func mirrorPodFilter(pod corev1.Pod) (bool, *warning, *fatal) {
    if _, found := pod.ObjectMeta.Annotations[corev1.MirrorPodAnnotationKey]; found {
        return false, nil, nil
    }
    return true, nil, nil
}

annotation の定義は pkg/apis/core/annotation_key_constants.go を参照する。

    // MirrorAnnotationKey represents the annotation key set by kubelets when creating mirror pods
    MirrorPodAnnotationKey string = "kubernetes.io/config.mirror"

kubernetes.io/config.mirror という annotation を持っているかどうかでフィルタされているようだ。

Mirror Pod って何だ？と思ってググると

Statis Pod が API server 側で見えるようになっているもの (見えるだけで API から制御できないもの) のことを指すらしい。

Static Pod は kubelet が API server ではなくファイルや HTTP 経由で渡された manifest を元に作成・起動した Pod のこと => Static Pods

調べてから見つけたが、詳しく説明している記事があった => Draining Kubernetes nodes

df によるディスク使用率計算

2020-10-14T22:55:58+09:00

Qrunch から引っ越し

計算方法

使用率はおおよそ以下のようになる。

ceil(100 * used / (used + avail))

size フィールドではなく used + avail になっているのは、ファイルシステムによる予約領域を考慮したためと思われる。

メモ

statfs(2) , statvfs(3)

これらを呼び出してファイルシステムの使用状況を取得する。

例えば statvfs(3) の manpage を見るとどのようなデータがあるのか書いてある。

struct statvfs {
    unsigned long  f_bsize;    /* file system block size */
    unsigned long  f_frsize;   /* fragment size */
    fsblkcnt_t     f_blocks;   /* size of fs in f_frsize units */
    fsblkcnt_t     f_bfree;    /* # free blocks */
    fsblkcnt_t     f_bavail;   /* # free blocks for unprivileged users */
    fsfilcnt_t     f_files;    /* # inodes */
    fsfilcnt_t     f_ffree;    /* # free inodes */
    fsfilcnt_t     f_favail;   /* # free inodes for unprivileged users */
    unsigned long  f_fsid;     /* file system ID */
    unsigned long  f_flag;     /* mount flags */
    unsigned long  f_namemax;  /* maximum filename length */
};

ファイルシステムの予約領域

ext4 はデフォルトで 5% が root ユーザ用に予約されているため、
f_bfree と f_bavail が一致しないことが多いだろう。

xfs は ext4 とはアプローチが異なり、ファイルを保存する領域に予約はなく f_bfree と f_bavail が一致するようだ。

参考：Does XFS have reserved space for the root user ?

df と snmpdf (Net-SNMP)

df は statvfs(3) などで取得した値を元に計算し、小数点以下は切り上げが行われる。

snmpdf は snmpd が statvfs(3) などで取得した値を受け取って計算し、小数点以下は切り捨てが行われるため、df コマンドの結果とは異なる場合がある。

psql (libpq) が subjectAltName の iPAddress を見ない

2020-10-14T22:54:34+09:00

Qrunch から引っ越し

ドキュメントを読むと IP アドレスでのサーバ証明書検証もやってくれそうな気配はある。

32.18.1. サーバ証明書のクライアント検証

もし接続がホスト名ではなくIPアドレスを使用するのであれば、（いかなるDNS検索もせず）IPアドレスがマッチさせられます。

しかし psql から IPアドレスで接続して証明書を検証させようとすると、以下のようなエラーになった。

$ psql "port=5432 host=192.0.2.1 sslcert=./user.crt sslkey=./user.key sslrootcert=./ca.crt sslmode=verify-full dbname=postgres user=user"
psql: server certificate for "example.com" (and 1 other name) does not match host name "192.0.2.1"

バージョン 9.6.9 の src/interfaces/libpq/fe-secure-openssl.c から関連部分を抜粋

verify_peer_name_matches_certificate()

    /*
     * First, get the Subject Alternative Names (SANs) from the certificate,
     * and compare them against the originally given hostname.
     */
    peer_san = (STACK_OF(GENERAL_NAME) *)
        X509_get_ext_d2i(conn->peer, NID_subject_alt_name, NULL, NULL);

    if (peer_san)
    {
        int         san_len = sk_GENERAL_NAME_num(peer_san);

        for (i = 0; i < san_len; i++)
        {
            const GENERAL_NAME *name = sk_GENERAL_NAME_value(peer_san, i);

            if (name->type == GEN_DNS)
            {
                char       *alt_name;

                names_examined++;
                rc = verify_peer_name_matches_certificate_name(conn,
                                                             name->d.dNSName,
                                                               &alt_name);
                if (rc == -1)
                    got_error = true;
                if (rc == 1)
                    found_match = true;

                if (alt_name)
                {
                    if (!first_name)
                        first_name = alt_name;
                    else
                        free(alt_name);
                }
            }
            if (found_match || got_error)
                break;
        }
        sk_GENERAL_NAME_free(peer_san);
    }

    /*
     * If there is no subjectAltName extension of type dNSName, check the
     * Common Name.
     *
     * (Per RFC 2818 and RFC 6125, if the subjectAltName extension of type
     * dNSName is present, the CN must be ignored.)
     */
    if (names_examined == 0)
    {
        X509_NAME  *subject_name;

        subject_name = X509_get_subject_name(conn->peer);
        if (subject_name != NULL)
        {
            int         cn_index;

            cn_index = X509_NAME_get_index_by_NID(subject_name,
                                                  NID_commonName, -1);
            if (cn_index >= 0)
            {
                names_examined++;
                rc = verify_peer_name_matches_certificate_name(
                                                               conn,
                                                    X509_NAME_ENTRY_get_data(
                                X509_NAME_get_entry(subject_name, cn_index)),
                                                               &first_name);

                if (rc == -1)
                    got_error = true;
                else if (rc == 1)
                    found_match = true;
            }
        }
    }

Subject Alternative Name に関しては
name->type == GEN_DNS なケースしかチェックしないので、DNS:example.com のような dNSName フィールドのみチェックし IP:192.0.2.1 のような iPAddress フィールドはスキップされるようだ。

CN に IP アドレスを入れておけば検証されると思われるが、
If there is no subjectAltName extension of type dNSName, check the Common Name. とコメントにある通り、subjectAltname に dNSName があったら CN のチェックも行われないので、名前との共存は望めないようだ。

証明書を発行する時に DNS:192.0.2.1 のように subjectAltName に dNSName として IP アドレスを入れてしまう細工しておくと検証に成功するが、素直に名前を使うのが良いだろう。