1 - HostAliasesを使用してPodの/etc/hostsにエントリーを追加する
Podの/etc/hostsファイルにエントリーを追加すると、DNSやその他の選択肢を利用できない場合に、Podレベルでホスト名の名前解決を上書きできるようになります。このようなカスタムエントリーは、PodSpecのHostAliasesフィールドに追加できます。
HostAliasesを使用せずにファイルを修正することはおすすめできません。このファイルはkubeletが管理しており、Podの作成や再起動時に上書きされる可能性があるためです。
デフォルトのhostsファイルの内容
Nginx Podを実行すると、Pod IPが割り当てられます。
kubectl run nginx --image nginx pod/nginx created Pod IPを確認します。
kubectl get pods --output=wide NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 13s 10.200.0.4 worker0 hostsファイルの内容は次のようになります。
kubectl exec nginx -- cat /etc/hosts # Kubernetes-managed hosts file. 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet fe00::0 ip6-mcastprefix fe00::1 ip6-allnodes fe00::2 ip6-allrouters 10.200.0.4 nginx デフォルトでは、hostsファイルには、localhostやPod自身のホスト名などのIPv4とIPv6のボイラープレートだけが含まれています。
追加エントリーをhostAliasesに追加する
デフォルトのボイラープレートに加えて、hostsファイルに追加エントリーを追加できます。たとえば、foo.localとbar.localを127.0.0.1に、foo.remoteとbar.remoteを10.1.2.3にそれぞれ解決するためには、PodのHostAliasesを.spec.hostAliases以下に設定します。
apiVersion: v1 kind: Pod metadata: name: hostaliases-pod spec: restartPolicy: Never hostAliases: - ip: "127.0.0.1" hostnames: - "foo.local" - "bar.local" - ip: "10.1.2.3" hostnames: - "foo.remote" - "bar.remote" containers: - name: cat-hosts image: busybox command: - cat args: - "/etc/hosts" この設定を使用したPodを開始するには、次のコマンドを実行します。
kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml pod/hostaliases-pod created Podの詳細情報を表示して、IPv4アドレスと状態を確認します。
kubectl get pod --output=wide NAME READY STATUS RESTARTS AGE IP NODE hostaliases-pod 0/1 Completed 0 6s 10.200.0.5 worker0 hostsファイルの内容は次のようになります。
kubectl logs hostaliases-pod # Kubernetes-managed hosts file. 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet fe00::0 ip6-mcastprefix fe00::1 ip6-allnodes fe00::2 ip6-allrouters 10.200.0.5 hostaliases-pod # Entries added by HostAliases. 127.0.0.1 foo.local bar.local 10.1.2.3 foo.remote bar.remote ファイルの最後に追加エントリーが指定されています。
kubeletがhostsファイルを管理するのはなぜですか？
kubeletがPodの各コンテナのhostsファイルを管理するのは、コンテナ起動後にDockerがファイルを編集するのを防ぐためです。
注意:
コンテナ内部でhostsファイルを手動で変更するのは控えてください。
hostsファイルを手動で変更すると、コンテナが終了したときに変更が失われてしまいます。
2 - IPv4/IPv6デュアルスタックの検証
このドキュメントでは、IPv4/IPv6デュアルスタックが有効化されたKubernetesクラスターを検証する方法について共有します。
始める前に
- プロバイダーがデュアルスタックのネットワークをサポートしていること (クラウドプロバイダーか、ルーティングできるIPv4/IPv6ネットワークインターフェースを持つKubernetesノードが提供できること)
- (KubenetやCalicoなど)デュアルスタックをサポートするネットワークプラグイン
- デュアルスタックを有効化したクラスター
バージョンを確認するには次のコマンドを実行してください: kubectl version.
アドレスの検証
ノードアドレスの検証
各デュアルスタックのノードは、1つのIPv4ブロックと1つのIPv6ブロックを割り当てる必要があります。IPv4/IPv6のPodアドレスの範囲が設定されていることを検証するには、次のコマンドを実行します。例の中のノード名は、自分のクラスターの有効なデュアルスタックのノードの名前に置換してください。この例では、ノードの名前はk8s-linuxpool1-34450317-0になっています。
kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .spec.podCIDRs}}{{printf "%s\n" .}}{{end}}' 10.244.1.0/24 2001:db8::/64 IPv4ブロックとIPv6ブロックがそれぞれ1つずつ割り当てられているはずです。
ノードが検出されたIPv4とIPv6のインターフェースを持っていることを検証します。ノード名は自分のクラスター内の有効なノード名に置換してください。この例では、ノード名はk8s-linuxpool1-34450317-0になっています。
kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .status.addresses}}{{printf "%s: %s\n" .type .address}}{{end}}' Hostname: k8s-linuxpool1-34450317-0 InternalIP: 10.0.0.5 InternalIP: 2001:db8:10::5 Podアドレスの検証
PodにIPv4とIPv6のアドレスが割り当てられていることを検証します。Podの名前は自分のクラスター内の有効なPodの名前と置換してください。この例では、Podの名前はpod01になっています。
kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{printf "%s\n" .ip}}{{end}}' 10.244.1.4 2001:db8::4 Downward APIを使用して、status.podIPsのfieldPath経由でPod IPを検証することもできます。次のスニペットは、Pod IPをMY_POD_IPSという名前の環境変数経由でコンテナ内に公開する方法を示しています。
env: - name: MY_POD_IPS valueFrom: fieldRef: fieldPath: status.podIPs 次のコマンドを実行すると、MY_POD_IPS環境変数の値をコンテナ内から表示できます。値はカンマ区切りのリストであり、PodのIPv4とIPv6のアドレスに対応しています。
kubectl exec -it pod01 -- set | grep MY_POD_IPS MY_POD_IPS=10.244.1.4,2001:db8::4 PodのIPアドレスは、コンテナ内の/etc/hostsにも書き込まれます。次のコマンドは、デュアルスタックのPod上で/etc/hostsに対してcatコマンドを実行します。出力を見ると、Pod用のIPv4およびIPv6のIPアドレスの両方が確認できます。
kubectl exec -it pod01 -- cat /etc/hosts # Kubernetes-managed hosts file. 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet fe00::0 ip6-mcastprefix fe00::1 ip6-allnodes fe00::2 ip6-allrouters 10.244.1.4 pod01 2001:db8::4 pod01 Serviceの検証
.spec.isFamilyPolicyを明示的に定義していない、以下のようなServiceを作成してみます。Kubernetesは最初に設定したservice-cluster-ip-rangeの範囲からServiceにcluster IPを割り当てて、.spec.ipFamilyPolicyをSingleStackに設定します。
apiVersion: v1 kind: Service metadata: name: my-service labels: app: MyApp spec: selector: app: MyApp ports: - protocol: TCP port: 80 kubectlを使ってServiceのYAMLを表示します。
kubectl get svc my-service -o yaml Serviceの.spec.ipFamilyPolicyはSingleStackに設定され、.spec.clusterIPにはkube-controller-manager上の--service-cluster-ip-rangeフラグで最初に設定した範囲から1つのIPv4アドレスが設定されているのがわかります。
apiVersion: v1 kind: Service metadata: name: my-service namespace: default spec: clusterIP: 10.0.217.164 clusterIPs: - 10.0.217.164 ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - port: 80 protocol: TCP targetPort: 9376 selector: app: MyApp sessionAffinity: None type: ClusterIP status: loadBalancer: {} .spec.ipFamilies内の配列の1番目の要素にIPv6を明示的に指定した、次のようなServiceを作成してみます。Kubernetesはservice-cluster-ip-rangeで設定したIPv6の範囲からcluster IPを割り当てて、.spec.ipFamilyPolicyをSingleStackに設定します。
apiVersion: v1 kind: Service metadata: name: my-service labels: app: MyApp spec: ipFamilies: - IPv6 selector: app: MyApp ports: - protocol: TCP port: 80 kubectlを使ってServiceのYAMLを表示します。
kubectl get svc my-service -o yaml Serviceの.spec.ipFamilyPolicyはSingleStackに設定され、.spec.clusterIPには、kube-controller-manager上の--service-cluster-ip-rangeフラグで指定された最初の設定範囲から1つのIPv6アドレスが設定されているのがわかります。
apiVersion: v1 kind: Service metadata: labels: app: MyApp name: my-service spec: clusterIP: 2001:db8:fd00::5118 clusterIPs: - 2001:db8:fd00::5118 ipFamilies: - IPv6 ipFamilyPolicy: SingleStack ports: - port: 80 protocol: TCP targetPort: 80 selector: app: MyApp sessionAffinity: None type: ClusterIP status: loadBalancer: {} .spec.ipFamiliePolicyにPreferDualStackを明示的に指定した、次のようなServiceを作成してみます。Kubernetesは(クラスターでデュアルスタックを有効化しているため)IPv4およびIPv6のアドレスの両方を割り当て、.spec.ClusterIPsのリストから、.spec.ipFamilies配列の最初の要素のアドレスファミリーに基づいた.spec.ClusterIPを設定します。
apiVersion: v1 kind: Service metadata: name: my-service labels: app: MyApp spec: ipFamilyPolicy: PreferDualStack selector: app: MyApp ports: - protocol: TCP port: 80 備考:
kubectl get svcコマンドは、CLUSTER-IPフィールドにプライマリーのIPだけしか表示しません。
kubectl get svc -l app=MyApp NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service ClusterIP 10.0.216.242 <none> 80/TCP 5s kubectl describeを使用して、ServiceがIPv4およびIPv6アドレスのブロックからcluster IPを割り当てられていることを検証します。その後、ServiceにIPアドレスとポートを使用してアクセスできることを検証することもできます。
kubectl describe svc -l app=MyApp Name: my-service Namespace: default Labels: app=MyApp Annotations: <none> Selector: app=MyApp Type: ClusterIP IP Family Policy: PreferDualStack IP Families: IPv4,IPv6 IP: 10.0.216.242 10.0.216.242,2001:db8:fd00::af55 Port: <unset> 80/TCP TargetPort: 9376/TCP Endpoints: <none> Session Affinity: None Events: <none> デュアルスタックのLoadBalancer Serviceを作成する
クラウドプロバイダーがIPv6を有効化した外部ロードバランサーのプロビジョニングをサポートする場合、.spec.ipFamilyPolicyにPreferDualStackを指定し、.spec.ipFamiliesの最初の要素をIPv6にして、typeフィールドにLoadBalancerを指定したServiceを作成できます。
apiVersion: v1 kind: Service metadata: name: my-service labels: app: MyApp spec: ipFamilyPolicy: PreferDualStack ipFamilies: - IPv6 type: LoadBalancer selector: app: MyApp ports: - protocol: TCP port: 80 Serviceを確認します。
kubectl get svc -l app=MyApp ServiceがIPv6アドレスブロックからCLUSTER-IPのアドレスとEXTERNAL-IPを割り当てられていることを検証します。その後、IPとポートを用いたServiceへのアクセスを検証することもできます。
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service LoadBalancer 2001:db8:fd00::7ebc 2603:1030:805::5 80:30790/TCP 35s 3 - Service IPの範囲を拡張する
Kubernetes v1.33 [stable](enabled by default)このドキュメントはクラスターに割り当てられている既存のService IPの範囲を拡張する方法を説明します。
始める前に
Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 まだクラスターがない場合、minikubeを使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます:
作業するKubernetesサーバーは次のバージョン以降のものである必要があります: v1.29.バージョンを確認するには次のコマンドを実行してください: kubectl version.
API
APIサーバーでMultiCIDRServiceAllocatorフィーチャーゲートを有効にし、networking.k8s.io/v1beta1APIグループをアクティブにしているKubernetesクラスターは、kubernetesという名前の特別なServiceCIDRオブジェクトを作成します。このオブジェクトには、APIサーバーのコマンドライン引数--service-cluster-ip-rangeの値に基づいたIPアドレス範囲が指定されます。
kubectl get servicecidr NAME CIDRS AGE kubernetes 10.96.0.0/28 17d APIサーバーのエンドポイントをPodに公開するkubernetesという特別なServiceは、デフォルトのServiceCIDRの範囲の最初のIPアドレスを算出し、そのIPアドレスをCluster IPとして使用します。
kubectl get service kubernetes NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 17d この例では、デフォルトのServiceはClusterIPとして10.96.0.1を使用しており、対応するIPAddressオブジェクトがあります。
kubectl get ipaddress 10.96.0.1 NAME PARENTREF 10.96.0.1 services/default/kubernetes ServiceCIDRはファイナライザーによって保護されており、ServiceのClusterIPが孤立することを防ぎます。ファイナライザーが削除されるのは、既存の全IPAddressを含む別のサブネットがある場合またはサブネットに属するIPAddressがない場合のみです。
Serviceに使用できるIPアドレスの個数を拡張する
ユーザーはServiceに使用できるアドレスの個数を増やしたい場合がありますが、従来はServiceの範囲を拡張することは破壊的な操作であり、データ損失につながる可能性もありました。この新しい機能を使用することで、ユーザーは新しいServiceCIDRを追加するだけで使用可能なアドレスを増やすことができます。
新しいServiceCIDRを追加する
Service用として10.96.0.0/28の範囲が設定されたクラスターでは、2^(32-28) - 2 = 14個のIPアドレスしか使用できません。kubernetes.defaultServiceは常に作成されるため、この例では最大13個しかServiceを作れません。
for i in $(seq 1 13); do kubectl create service clusterip "test-$i" --tcp 80 -o json | jq -r .spec.clusterIP; done 10.96.0.11 10.96.0.5 10.96.0.12 10.96.0.13 10.96.0.14 10.96.0.2 10.96.0.3 10.96.0.4 10.96.0.6 10.96.0.7 10.96.0.8 10.96.0.9 error: failed to create ClusterIP service: Internal error occurred: failed to allocate a serviceIP: range is full IPアドレス範囲を拡張または追加する新しいServiceCIDRを作成することで、Serviceに使用できるIPアドレスの個数を増やせます。
cat <EOF | kubectl apply -f - apiVersion: networking.k8s.io/v1beta1 kind: ServiceCIDR metadata: name: newcidr1 spec: cidrs: - 10.96.0.0/24 EOF servicecidr.networking.k8s.io/newcidr1 created これにより、新しいServiceを作成できるようになり、新しい範囲からClusterIPが割り当てられます。
for i in $(seq 13 16); do kubectl create service clusterip "test-$i" --tcp 80 -o json | jq -r .spec.clusterIP; done 10.96.0.48 10.96.0.200 10.96.0.121 10.96.0.144 ServiceCIDRの削除
あるServiceCIDRに依存しているIPAddressが存在する場合、そのServiceCIDRは削除できません。
kubectl delete servicecidr newcidr1 servicecidr.networking.k8s.io "newcidr1" deleted KubernetesはServiceCIDRのファイナライザーを使ってこの依存関係を追跡します。
kubectl get servicecidr newcidr1 -o yaml apiVersion: networking.k8s.io/v1beta1 kind: ServiceCIDR metadata: creationTimestamp: "2023-10-12T15:11:07Z" deletionGracePeriodSeconds: 0 deletionTimestamp: "2023-10-12T15:12:45Z" finalizers: - networking.k8s.io/service-cidr-finalizer name: newcidr1 resourceVersion: "1133" uid: 5ffd8afe-c78f-4e60-ae76-cec448a8af40 spec: cidrs: - 10.96.0.0/24 status: conditions: - lastTransitionTime: "2023-10-12T15:12:45Z" message: There are still IPAddresses referencing the ServiceCIDR, please remove them or create a new ServiceCIDR reason: OrphanIPAddress status: "False" type: Ready ServiceCIDRの削除を止めているIPAddressを含むServiceを削除すると
for i in $(seq 13 16); do kubectl delete service "test-$i" ; done service "test-13" deleted service "test-14" deleted service "test-15" deleted service "test-16" deleted コントロールプレーンがそれを検知します。そしてコントロールプレーンはファイナライザを削除し、削除が保留されているServiceCIDRが実際に削除されるようにします。
kubectl get servicecidr newcidr1 Error from server (NotFound): servicecidrs.networking.k8s.io "newcidr1" not found