alicek106 / start-docker-kubernetes Goto Github PK

View Code? Open in Web Editor NEW

250.0 8.0 108.0 67 KB

시작하세요! 도커, 그리고 쿠버네티스 책에서 사용되는 예제를 정리한 저장소입니다.

Dockerfile 8.20% Shell 1.41% Python 27.31% HCL 63.08%

start-docker-kubernetes's Introduction

시작하세요! 도커, 그리고 쿠버네티스

위키북스 '시작하세요! 도커, 그리고 쿠버네티스' 책에서 쓰이는 예제와 강의를 모아둔 저장소입니다. 책 내용의 질문을 issue에 올려주셔도 됩니다.

1부. Docker

chapter 2 : fluentd_mongo
chapter 3 : nfs_server

2부. Kubernetes

책의 예제에서 사용하는 YAML 파일 목록

chapter 6 : 포드, 레플리카셋, 디플로이먼트, 서비스
chapter 7 : 네임스페이스, 컨피그맵, 시크릿
chapter 8 : 인그레스
chapter 9 : 퍼시스턴트 볼륨, 퍼시스턴트 볼륨 클레임
chapter 10 : 서비스 어카운트, RBAC
chapter 11-1: 리소스 관리
chapter 11-2 : 스케줄링
chapter 11-3 : 애플리케이션 상태와 배포
chapter 12 : 커스텀 리소스
chapter 13 : 포드를 사용하는 다른 리소스 (스테이트풀셋, 잡, 데몬셋)

그 밖의 유용한 강좌 링크

start-docker-kubernetes's People

Contributors

Stargazers

Watchers

Forkers

anything3 mannue enmhjlee gyeyeong mz-leo palbahngmiyine sunpyopark sup2is fresh-tuna yowo100 hadaberji jayden-lee songhayoung stevenkim18 unbreaks88 jokuna gyuhyoung hshine1226 nowjean almyk donghyukki pheeing cprayer pakanii godekdls asprin107 hyunstory terri1102 maxhyeon drinkwhale dhkdn9192 kanghyejin0106 hyukjj devholic77 kim-kyungtae paikend kidmam pettizel yuyu2323 ryanking-github sjoh0704 jcyeom eeta justin95214 namrmino ycyangman livenow14 sihyung92 theprismdata bokbutcode limdaesun holly-park uthline jameskim-ai sangminnn intiwatana snapbuy herdin paternallove kakao-jm-hong whykikiki dev-0ops ghoon-lee namki-hub seongilp y-jaehyun ununbum mr-dogi yahanjunho chaejieun giwonn jionederfull itguny04 sn-hn ingiljang kiss7001 github010000 randomshot allendy11 starman3ch lovealakazam korwoo93 deveopser goodbyeramsay zzls12 slowth-kim keemdy ssol-park jcwee0873 ohjinhokor kokomai parkinhyo young-hun-jo kevinwoos myinno lbs3828 ktdswelcomeproj sangjunryu gkm2019 onemorestep-study

start-docker-kubernetes's Issues

p319 ClusterIP 서비스 이름으로 요청 시, 내장 DNS Error

안녕하세요. 책 319쪽에서 ClusterIP 유형의 서비스를 생성해서 해당 서비스의 이름으로 요청을 테스트 하고 있는데요? 서비스의 IP 로 요청을 하면 응답값이 잘 나오는데, IP 부분을 서비스 이름으로 대신했을 때는 에러가 발생하는데요? 아무래도 쿠버네티스 내장 DNS가 서비스 이름을 IP로 매핑하지 못하는 것 같아요..

curl: (6) Could not resolve host: zedd-hostname-svc-clusterip

그래서 구글링을 좀 해보니, 내장 DNS 서버가 띄워져 있는 파드가 잘 실행되고 있는지도 보았는데, 잘 실행되고 있더라구요?
그리고 dnsutils 팟을 생성해서 DNS 서버 체크도 해보았는데, 이것도 잘 동작하고 있더라구요(링크)

쿠버네티스 설치환경은 책에서 제안해주신 것과 동일한 상태입니다.

저자 분이 생각하시기에 가능성 있는 원인이 있으실지 문의드립니다!

p.42 / 2.2.6.1 호스트 볼륨 공유 / db파일 생성 안돼요!

42p에서 db와 wordpress 컨테이너를 각각 생성하여 볼륨을 공유하였습니다.

명령어 작성 후 db 컨테이너에 exec로 접속하여 /home/wordpress_db 폴더를 확인 해 보았는데 존재하지 않습니다.

혹시 공유 디렉토리라 함은 host(사용자) 디렉토리랑 공유된다는 말씀이신가요?

제가 윈도우10 사용중이라 디렉토리 생성 위치를 몰랐던거도 같습니다..

답변부탁드립니다!

p382 Ingress-example.yaml파일에 대한 질문

안녕하세요. 책 관련하여 질문 드리겠습니다.

spec.rules.host에 대해서
해당 도메인 이름으로 접근하는 요청에 대해서 처리 규칙을 적용한다. 라고 나와있는데요.
현재 저는 openstack 4개의 노드들 위에 k8s클러스터를 구축하고 있습니다.
ingress를 loadbalancer타입으로 생성하면 오픈스택 cloud provider가 옥타비아(오픈스택에서 제공하는 로드밸런서)를 동적으로 생성할 것이라고 생각합니다.
그러면 이러한 환경에서 dns에 동적으로 도메인이 설정 되어야 된다고 생각되는데 오픈스택 환경에서도 가능 할까요?

[p.190,191] 도커 스웜을 학습하기 위한 질문

@alicek106
안녕하세요! 책 잘 보고 있습니다. 제목에 작성한 것처럼 책 190,191 쪽에서 궁금한 점이 생겼는데요!? 도커 스웜 자체에 대한 질문은 아니고.. 책에서 도커 스웜이 필요한 이유를 설명해주시기 위해 작성하신 글을 읽다보니 문득 궁금한 점이 생겨 질문드립니다.

서버 N대가 1개의 공통된 도커 엔진을 사용할 수 있는 건가요?
ㄴ 저는 그럴 수 있다고 생각하는데요? 배웠다시피 도커 엔진에는 도커 클라이언트/도커 데몬으로 구성되잖아요? 예를 들어, 서버 1,2,3,4가 있고 서버 1에서 도커 데몬이 실행되고 있다고 가정해볼게요. 그러면 서버 2,3,4는 Remote API를 사용해서 서버 1의 도커 데몬과 통신하게 된다면 결국 서버 N대가 1개의 공통된 도커 엔진(엄밀히 말하면 1개의 도커 데몬)을 사용할 수 있다고 할 수 있는 건가요?
1번에서 질문드린 상황처럼 N대의 서버가 1개의 도커 데몬을 공통적으로 사용하는 구조가 일반적으로 권장되는 구조인가요?
도커 스웜 모드를 활성화 한다고 하면 1개의 도커 엔진 안에서의 도커 데몬이 1개 -> N개로 늘어나는 건가요?
도커 스웜 모드를 구성하는 '매니저 노드' 와 '워커 노드'는 '도커 데몬'의 일종인 건가요? '매니저, 워커 노드'가 '도커 데몬'에 종속되는 관계인 건지.. 어떤 관계로 구성되는 건지 궁금합니다!(자세한 관계보다는 '도커 데몬' 과 종속되는 관계인지 아닌지와 같은 큰 그림을 알고 싶네요..)

아직 도커 스웜 부분을 다 읽지 않아서.. 책에 나오는 부분인데 제가 중복해서 드리는 질문일 수도 있는데요.. 도커 스웜 개념을 들어가기 전에 나름 기초(?)를 탄탄하게 하고자 하는 목적이라서.. 답변 달아주시면 정말 감사하겠습니다 😀

CertificateSigningRequest의 yaml인 chapter10/alicek106-csr.yaml에서 오류 발생

안녕하세요.
github에 있는 파일로 실습하던 중 해당 리소스를 만드는 yaml에서 오류가 나서 이슈를 올렸습니다.

apiVersion

에러

apiVersion이 맞지 않아 다음의 에러가 발생합니다.

start-docker-kubernetes/chapter10/alicek106-csr.yaml

Line 1 in 9ec196a

apiVersion: certificates.k8s.io/v1beta1

error: unable to recognize "alicek106-csr.yaml": no matches for kind "CertificateSigningRequest" in version "certificates.k8s.io/v1beta1"

해결

apiVersion: certificates.k8s.io/v1으로 변경시 해결됩니다.

singerName

에러

required field인 singerName이 없어 다음의 에러가 발생합니다. 공식 문서에 " Note that spec.signerName is a required key after API version certificates.k8s.io/v1" 라고 나와있습니다.

error: error validating "alicek106-csr.yaml": error validating data: ValidationError(CertificateSigningRequest.spec): missing required field "signerName" in io.k8s.api.certificates.v1.CertificateSigningRequestSpec; if you choose to ignore these errors, turn validation off with --validate=false

해결

signerName: kubernetes.io/kube-apiserver-client을 추가하면 해결됩니다.
여러 singerName이 있는데, 위의 singerName을 쓰는 게 맞는지 확신은 못하겠습니다.

교재를 통해 쿠버네티스에 대해 잘 배우고 있습니다. 🙂
감사합니다.

wsl2에 설치된 minikube에서 Ch.6.5.3 NordePort 타입 서비스 클러스터 외부 접근이 안됩니다

윈도우10 WSL2 backend로 docker를 사용하고 minkube를 설치하였습니다.
제 개인 노트북에서 실행해 보고 있어서 master node 하나입니다.

$ kubectl version --short
Client Version: v1.19.3
Server Version: v1.19.4

solla@DESKTOP-OE59N3T:~/mlops/MiniKube$ kubectl get svc
NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
frontend                NodePort    10.100.71.70     <none>        80:31940/TCP     42m
hostname-svc-nodeport   NodePort    10.110.104.166   <none>        8080:30608/TCP   10m
kubernetes              ClusterIP   10.96.0.1        <none>        443/TCP          14h
redis-master            ClusterIP   10.103.153.31    <none>        6379/TCP         52m
redis-slave             ClusterIP   10.110.251.110   <none>        6379/TCP         46m
solla@DESKTOP-OE59N3T:~/mlops/MiniKube$ kubectl get pod
NAME                                   READY   STATUS    RESTARTS   AGE
debug                                  1/1     Running   0          37m
frontend-6c6d6dfd4d-jpr6w              1/1     Running   0          45m
frontend-6c6d6dfd4d-rlx5n              1/1     Running   0          45m
frontend-6c6d6dfd4d-wvq8j              1/1     Running   0          45m
hostname-deployment-7dfd748479-gxwcl   1/1     Running   0          11m
hostname-deployment-7dfd748479-pbtwk   1/1     Running   0          11m
hostname-deployment-7dfd748479-rzg4v   1/1     Running   0          11m
redis-master-f46ff57fd-4mxq7           1/1     Running   0          54m
redis-slave-bbc7f655d-hwqxj            1/1     Running   0          47m
redis-slave-bbc7f655d-kvlgn            1/1     Running   0          47m
solla@DESKTOP-OE59N3T:~/mlops/MiniKube$ kubectl exec --stdin --tty debug -- /bin/bash
root@debug:/# curl 10.110.104.166:8080
<!DOCTYPE html>
<meta charset="utf-8" />
<link rel="stylesheet" type="text/css" href="./css/layout.css" />
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.2/css/bootstrap.min.css">

<div class="form-layout">
        <blockquote>
        <p>Hello,  hostname-deployment-7dfd748479-rzg4v</p>     </blockquote>
</div>
root@debug:/# ^C
root@debug:/# exit
exit
command terminated with exit code 130

solla@DESKTOP-OE59N3T:~/mlops/MiniKube$ kubectl get svc
NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
frontend                NodePort    10.100.71.70     <none>        80:31940/TCP     45m
hostname-svc-nodeport   NodePort    10.110.104.166   <none>        8080:30608/TCP   13m
kubernetes              ClusterIP   10.96.0.1        <none>        443/TCP          14h
redis-master            ClusterIP   10.103.153.31    <none>        6379/TCP         55m
redis-slave             ClusterIP   10.110.251.110   <none>        6379/TCP         49m
solla@DESKTOP-OE59N3T:~/mlops/MiniKube$ kubectl get nodes -o wide
NAME       STATUS   ROLES    AGE   VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION                CONTAINER-RUNTIME
minikube   Ready    master   14h   v1.19.4   192.168.49.2   <none>        Ubuntu 20.04.1 LTS   4.19.128-microsoft-standard   docker://19.3.13
solla@DESKTOP-OE59N3T:~/mlops/MiniKube$ curl 192.168.49.2:30608
curl: (28) Failed to connect to 192.168.49.2 port 30608: Connection timed out

metics-server 설치 후에 unable to fetch pod metrics for pod/node 오류

안녕하세요. 책을 구매 후 친절하신 설명으로 쿠베를 배우고 있습니다.

책을 따라하던중 14장 모니터링으로 metics-server 를 설치 했습니다.
아래는 component.yaml 입니다.

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: system:aggregated-metrics-reader
  labels:
    rbac.authorization.k8s.io/aggregate-to-view: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
rules:
- apiGroups: ["metrics.k8s.io"]
  resources: ["pods", "nodes"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: metrics-server:system:auth-delegator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: metrics-server-auth-reader
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: extension-apiserver-authentication-reader
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: apiregistration.k8s.io/v1beta1
kind: APIService
metadata:
  name: v1beta1.metrics.k8s.io
spec:
  service:
    name: metrics-server
    namespace: kube-system
  group: metrics.k8s.io
  version: v1beta1
  insecureSkipTLSVerify: true
  groupPriorityMinimum: 100
  versionPriority: 100
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: metrics-server
  namespace: kube-system
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: metrics-server
  namespace: kube-system
  labels:
    k8s-app: metrics-server
spec:
  selector:
    matchLabels:
      k8s-app: metrics-server
  template:
    metadata:
      name: metrics-server
      labels:
        k8s-app: metrics-server
    spec:
      serviceAccountName: metrics-server
      volumes:
      # mount in tmp so we can safely use from-scratch images and/or read-only containers
      - name: tmp-dir
        emptyDir: {}
      containers:
      - name: metrics-server
        image: k8s.gcr.io/metrics-server/metrics-server:v0.3.7
        imagePullPolicy: IfNotPresent
        args:
          - --cert-dir=/tmp
          - --secure-port=4443
          - --kubelet-insecure-tls
          - --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP
        ports:
        - name: main-port
          containerPort: 4443
          protocol: TCP
        securityContext:
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          runAsUser: 1000
        volumeMounts:
        - name: tmp-dir
          mountPath: /tmp
      hostNetwork: true
      nodeSelector:
        kubernetes.io/os: linux
---
apiVersion: v1
kind: Service
metadata:
  name: metrics-server
  namespace: kube-system
  labels:
    kubernetes.io/name: "Metrics-server"
    kubernetes.io/cluster-service: "true"
spec:
  selector:
    k8s-app: metrics-server
  ports:
  - port: 443
    protocol: TCP
    targetPort: main-port
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: system:metrics-server
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - nodes
  - nodes/stats
  - namespaces
  - configmaps
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:metrics-server
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-server
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system

설치 후에 top node 명령어를 실행해 보면 worker node 가 unknwon 이 나옵니다.

top pod 을 보면 디폴트 namespace 에 pods 도 아래 처럼 나옵니다.

매트릭 서버 로그는 아래와 같습니다.

추가로 클러스트 설정에 아래처럼 했음에도 불구하고 결과는 같았습니다.

kubelet:
    anonymousAuth: false
    authenticationTokenWebhook: true
    authorizationMode: Webhook

kubeadm을 통해 생성한 클러스터가 짧은 시간 후 사용 불가 상태가 되는 문제

안녕하세요. 20년에 출판해주신 책을 통해 잘 공부하고 있습니다. 좋은 책 감사합니다.
실습 중 잘 안 되는 것이 있어 문의를 드리려고 찾아뵈었습니다.

2부 5장의 kubeadm을 이용한 컨트롤 플레인에서의 클러스터 구축이 잘 되지 않아 문의드립니다. 검색도 많이 해봤지만 극히 기초적인 단계에서 발생한 문제임에도 도움이 되는 것을 찾지 못했습니다.

우선 테스트 환경은 간단하게 다음과 같았습니다.
플랫폼: AWS 내 우분투 22.04 LTS, 그리고 로컬 머신 내 VM 머신의 우분투 22.04 LTS 모두 테스트
사용 CRI: containerd
버전: 쿠버네티스 1.26을 포함한 모든 구성요소 최신 버전(별도 버전 지정을 하지 않음)

참고로 책의 예제 중 (아주 적지만)일부분은 현재 시점에선 잘 동작하지 않아 아래 공식 사이트의 가이드를 보며 진행했습니다.
containerd 설치 전 준비 : https://kubernetes.io/docs/setup/production-environment/container-runtimes/
containerd 설치(도커엔진과 함께 패키지로 설치) : https://github.com/containerd/containerd/blob/main/docs/getting-started.md
kubeadm 설치 : https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/
kubeadm으로 컨트롤 플레인 노드에 클러스터 생성 : https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/

증상은 kubeadm init으로 클러스터 기동 직후 쿠버네티스의 기본 컨테이너들(kube-apiserver, kube-controller-manager, kube-proxy, kube-scheduler)이 마치 정상적으로 기동된 것처럼 보이지만 컨테이너들이 죽고 리스타트를 반복하다가 일정 시점 이후로는 kube-apiserver의 6443 포트가 닫혀 어떤 컨트롤도 불가능하게 됩니다. 정확히 특정하진 않았지만 기동부터 완전히 먹통이 되기까지 약 5~10분 정도가 소요되는 것 같습니다. 참고로 본 문제는 CNI 플러그인 설치 이전에 발생하며 워커 노드는 참여시키지 않았습니다.

아래는 기동 시 메시지이며 별다른 문제는 없어보입니다.

root@kube-control:/var/log/containers# kubeadm init --apiserver-advertise-address 192.168.132.131 --pod-network-cidr=192.167.0.0/16

[init] Using Kubernetes version: v1.26.0
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kube-control kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.132.131]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [kube-control localhost] and IPs [192.168.132.131 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [kube-control localhost] and IPs [192.168.132.131 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 4.501740 seconds
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node kube-control as control-plane by adding the labels: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
[mark-control-plane] Marking the node kube-control as control-plane by adding the taints [node-role.kubernetes.io/control-plane:NoSchedule]
[bootstrap-token] Using token: ys42dt.iy4mfur22loefwat
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.132.131:6443 --token ys42dt.iy4mfur22loefwat \
	--discovery-token-ca-cert-hash sha256:0b6e9766c12499bad2ef737a3022ae5ab1bee839d0c44801f9025a92895222e7

그리고 아래는 기동 후 정상적인 모습부터 점차 리스타트가 증가하고 컨테이너들이 죽는 모습입니다.(다수의 시도로 일부 컨테이너의 리스타트 숫자가 많이 누적되어 있습니다)

root@kube-control:/var/log/containers# kubectl get pods --all-namespaces
NAMESPACE     NAME                                   READY   STATUS    RESTARTS        AGE
kube-system   coredns-787d4945fb-tjmxl               0/1     Pending   0               42s
kube-system   coredns-787d4945fb-z4p7r               0/1     Pending   0               42s
kube-system   etcd-kube-control                      1/1     Running   31 (108s ago)   75s
kube-system   kube-apiserver-kube-control            1/1     Running   31 (78s ago)    111s
kube-system   kube-controller-manager-kube-control   1/1     Running   14 (108s ago)   111s
kube-system   kube-proxy-nvfqf                       1/1     Running   1 (41s ago)     42s
kube-system   kube-scheduler-kube-control            1/1     Running   34 (108s ago)   110s

root@kube-control:/var/log/containers# kubectl get pods --all-namespaces
NAMESPACE     NAME                                   READY   STATUS             RESTARTS         AGE
kube-system   coredns-787d4945fb-tjmxl               0/1     Pending            0                2m18s
kube-system   coredns-787d4945fb-z4p7r               0/1     Pending            0                2m18s
kube-system   etcd-kube-control                      1/1     Running            31 (3m24s ago)   2m51s
kube-system   kube-apiserver-kube-control            1/1     Running            31 (2m54s ago)   3m27s
kube-system   kube-controller-manager-kube-control   1/1     Running            14 (3m24s ago)   3m27s
kube-system   kube-proxy-nvfqf                       1/1     Running            3 (34s ago)      2m18s
kube-system   kube-scheduler-kube-control            0/1     CrashLoopBackOff   36 (14s ago)     3m26s

root@kube-control:/var/log/containers# kubectl get pods --all-namespaces
NAMESPACE     NAME                                   READY   STATUS    RESTARTS         AGE
kube-system   coredns-787d4945fb-tjmxl               0/1     Pending   0                4m14s
kube-system   coredns-787d4945fb-z4p7r               0/1     Pending   0                4m14s
kube-system   etcd-kube-control                      1/1     Running   31 (5m20s ago)   4m47s
kube-system   kube-apiserver-kube-control            1/1     Running   32 (84s ago)     5m23s
kube-system   kube-controller-manager-kube-control   1/1     Running   15 (102s ago)    5m23s
kube-system   kube-proxy-nvfqf                       1/1     Running   4 (48s ago)      4m14s
kube-system   kube-scheduler-kube-control            1/1     Running   37 (2m10s ago)   5m22s

root@kube-control:/var/log/containers# kubectl get pods --all-namespaces
NAMESPACE     NAME                                   READY   STATUS             RESTARTS         AGE
kube-system   coredns-787d4945fb-tjmxl               0/1     Pending            0                5m24s
kube-system   coredns-787d4945fb-z4p7r               0/1     Pending            0                5m24s
kube-system   etcd-kube-control                      1/1     Running            32 (62s ago)     5m57s
kube-system   kube-apiserver-kube-control            1/1     Running            32 (2m34s ago)   6m33s
kube-system   kube-controller-manager-kube-control   0/1     CrashLoopBackOff   16 (10s ago)     6m33s
kube-system   kube-proxy-nvfqf                       0/1     CrashLoopBackOff   4 (14s ago)      5m24s
kube-system   kube-scheduler-kube-control            0/1     CrashLoopBackOff   37 (46s ago)     6m32s

root@kube-control:/var/log/containers# kubectl get pods --all-namespaces
The connection to the server 192.168.132.131:6443 was refused - did you specify the right host or port?
(이후 완전히 접근 불가)

너무 기본적인 부분에서 막혀서 며칠 째 자체 해결을 시도해봤으나 원인을 찾을 수 없어 문의드립니다.
확인에 추가로 필요한 로그가 있다면 말씀 부탁드립니다. 감사합니다.

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - 의 에러

현재 오픈스택 vm들을 만들어서 쿠버 환경을 구축하려고 합니다.

책 279페이지의 쿠버네티스 저장소 추가 관련 명령어
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
실행 했을경우 아래의 에러가 발생합니다.
gpg: no valid OpenPGP data found.

원인가 해결방안을 알려주세요

[p.92] 이미지 삭제 시 질문

@alicek106
안녕하세요~ 책 여전히 잘 읽고 있습니다. 92쪽 [이미지 삭제] 챕터와 관련하여 한 가지 질문드리고 싶은 게 있는데요? 책에서 예시를 들어주신 것처럼 아래와 같이 3개의 컨테이너가 존재한다고 가정해볼게요!

책에서, image A, B를 각각 삭제할 때 경우를 들어주셔서 설명해주셨는데요? 제가 궁금한 부분은 image A를 삭제할 때인데요?
일단, image A를 삭제하기 위해서는 "image A를 부모로하는 image B(자식 이미지)가 존재하지 않아야 실질적인 삭제가 가능하다" 라고 하셨는데요? 그런데 여기에 추가로 image A를 삭제하기 위해서는 "image A의 부모 이미지인 ubuntu:14.04 이미지를 삭제해야 한다"는 조건도 만족해야 하는 거 아닌가요? 즉, 이 2가지 조건을 모두 만족(and 조건)해야 실질적으로 image A가 삭제되는 것인지, 둘 중 하나만 만족(or 조건)해도 삭제되는 것인지 궁금하네요!

이렇게 생각한 이유는 image B를 삭제할 때 붙는 조건 때문인데요? image B를 삭제할 때 "image B의 부모 이미지인 image A가 존재하지 않아야 한다" 라고 하셨는데요? 그렇다면 "image A" 입장에서는 image A의 부모 이미지가 ubuntu14.04 이미지이기 때문이라고 생각했는데요? 이에 대한 답변 가능하신지 문의드려요!

images

서비스어카운트 생성시 시크릿 자동 생성 안됨

kubeadm 을 이용해서 설치를 했는데 v1.27.2 버전이 설치되어 있습니다.

p450에 보면 중간 즈음에 서비스어카운트를 생성하면 이에 대응하는 시크릿이 자동으로 생성된다고 나와 있는데, 아무래도 버전이 올라가면서 자동 생성이 되지 않는 것으로 보입니다. 최근 버전에서는 ~p453 까지의 인증 처리를 어떤식으로 진행해야 하나요?

[p.132] 멀티 스테이지 Dockerfile 빌드 실습 관련 질문

@alicek106
안녕하세요 멀티 스테이지 Dockerfile 빌드하는 실습 관련해서 질문이 있습니다! 제가 Go언어는 잘 몰라서.. 익숙한 python으로 책에서 해주신 것처럼 비슷하게 실습을 해보고 있는데요? 우선 멀티 스테이지 Dockerfile 과 표준출력 함수 파일은 아래와 같습니다!

# main.py
def f():
    return "Hello world"

FROM python:3.10.1
ADD main.py /root
WORKDIR /root
RUN python main.py

FROM alpine:latest
WORKDIR /root/alpine
COPY --from=0 /root /root/alpine
CMD ["/bin/sh", "-c", "python /root/alpine/main.py"]

궁금한 점은 아래와 같은데요?

위 Dockerfile로 만든 이미지를 기반으로 컨테이너를 생성하면 해당 컨테이너 내부에 python 설치가 되어 있지 않다는 에러가 발생하면서 컨테이너가 생성되자마자 바로 종료(Exited)됩니다. 책에서 배운 내용에 의하면.. --from=0 가 첫번째 FROM에서 빌드된 이미지의 최종 상태를 의미하고, 이를 복사해서 두번째 이미지인 alpine:latest 에 그대로 붙여넣기 하게 되면 저는 당연히 alpine:latest에도 python이 내장 설치되어 있을거라고 생각했는데요? 왜냐하면 첫번째 FROM 이미지가 파이썬 이미지 이기 때문이라고 생각했습니다. 이게 아닌 건가요..? 아니면 alpine:latest 이미지에서 python 설치는 또 따로 해주어야 하는 건가요..? 제가 어떤 부분을 놓치고 있는건지.. 질문드립니다!

그리고 한 가지 추가적으로 제가 알아본 것은 위 Dockerfile로 만든 이미지를 기반으로 컨테이너를 생성하는데, docker run 명령어에 COMMAND 인자에 /bin/sh 로 overwrite를 해서 컨테이너 내부에 들어가보니 저 main.py 파일이 제가 원하는 /root/alpine 경로에 복사되어 있는 것은 확인했습니다. 다만, python이 설치되어 있지 않다보니 python main.py 명령어를 치면 역시 에러가 나네요...ㅠ

[책 p.29] Docker Desktop for Mac 사용 시, 컨테이너를 외부에 노출할 때 질문입니다

안녕하세요? 출판해주신 책을 통해 도커와 쿠버네티스를 입문하고 있는 사람입니다. 우선 좋은 책을 출간해주셔서 감사인사부터 드립니다. 다름이 아니라 책으로 공부하다가 궁금한 점이 생겨 질문드립니다!

우선 책 29페이지의 하단 주석에 보면 Docker Desktop for Mac 도커 엔진을 이용하면 로컬 호스트에서 컨테이너 IP로 접근이 불가능하다고 적어주셨는데요? 제가 이전에 도커를 잠깐 얕게(?) 공부할 적엔 Docker Desktop for Mac 도커 엔진을 사용했었는데, 그 때 당시에 포트 포워딩 기능(-p 옵션)을 활용해 로컬 호스트와 컨테이너 포트를 연결하고, 볼륨 기능(-v)을 활용해 로컬 호스트와 컨테이너의 파일 시스템을 연결했을 때는 로컬 호스트에서 컨테이너 IP에 접근이 가능했는데요?

그러면 주석에 써주신 것처럼 "Docker Desktop for Mac 도커 엔진을 이용하면 로컬 호스트에서 컨테이너 IP로 접근이 불가능하다" 라는 것은 포트 포워딩 기능(-p 옵션)만 사용했을 때는 불가능하지만, 볼륨 기능(-v 옵션)을 활용하면 가능해진다로 이해하면 될까요!? 다시 말해, 볼륨 이라는 기능이 Docker Desktop for Mac 도커 엔진에서 로컬 호스트에서 컨테이너 IP로 접근을 가능하게 해주는 것인지 궁금합니다!

답변 천천히 달아주셔도 좋습니다. 기다리고 있겠습니다. 감사합니다 :)

p.35~p.36 / 호스트 IP와 워드프레스 컨테이너 포트로 웹 서버 접근이 안됩니다!

p.35 의 코드 그대로 데이터베이스, 워드프레스 웹 서버 컨테이너를 생성 및 연동 했는데요.
웹 브라우저로 접근했을 때 화면에 'Error establishing a database connection' 로 노출됩니다.
혹시 mysql 버전을 다르게 하거나 하는 해결 방법이 있을까요? 아님 제가 잘못 작성한 부분이 있을까요? ㅠㅠ

API Version v1beta1 Ingress 지원 종료

https://kubernetes.io/docs/reference/using-api/deprecation-guide/#ingress-v122

Chapter8 Ingress yaml 파일이 제대로 동작하지 않는 것 같습니다!

chapter8/Ingress-example.yaml에 대한 질문입니다.

저는 on-premise 환경에서 kubeadm 으로 클러스터 구성하여 공부를 하는 중입니다.
ingress 구성에 관련하여 질문을 두가지 드리고 싶습니다.

namespace 관련 질문입니다.

chapter8/Ingress-example.yaml 파일에는 metadata에 namespace를 설정하는 문구가 없기 때문에
default namespace (이하 ns)로 ingress resource가 생성될 것으로 생각됩니다.
하지만 chapter8/ingress-nginx-svc-nodeport.yaml 파일에서는 ingress controller resource를 ingress-nginx ns에 생성되도록 작성되어 있는것 같은데 default ns에 생성된 ingress를 ingress-nginx ns에 생성된 ingress controller가 참조가 가능한지 여쭤보고 싶습니다.

Ingress 생성 시 host spec 관련 질문입니다.

chapter8/Ingress-example.yaml의 spec.ruels.host에 alicek106.example.com으로 예시가 되어 있고,
p.384의 아래 Tip 에서 /etc/hosts에 ingress-controller로 접근할 수 있는 IP로 domain을 등록하여 테스트 해볼 수 있다고 하셨습니다.
우선 chapter8/ingress-nginx-svc-nodeport.yaml을 사용하여 Nginx ingress controller를 생성하려고 했지만 ingress-nginx namespace가 없어서, yaml 파일을 수정하여 임의로 생성한 뒤 apply를 해두었습니다. 그리고 chapter8/ingress-example.yaml 또한 apply 했습니다.
또한 책에서 chapter8/ingress-nginx-svc-nodeport.yaml을 통해 Nginx ingress controller를 생성하면 각 노드의 랜덤한 포트로 ingress controller에 접근이 가능하다고 설명이 되어 있으므로 아래의 step으로 테스트 진행하는 것이 맞는지 여쭤보고 싶습니다.

worker node에 network가 닿는 임의의 machine에서 /etc/hosts을 수정
- 수정 내용: 임의의 worker node의 IP 그리고 ingress에서 설정한 domain을 추가
curl을 통해 테스트 curl --resolve alicek106.example.com:31000:<node 중 하나의 IP> alicek106.example.com:31000/echo-hostname
- 제가 이해한대로면 curl 명령어에 <node 중 하나의 IP>가 총 3번(alicek106.example.com 2번 IP 입력 1번) 사용될 것 같습니다.

현재 상태의 테스트 결과

<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx</center>
</body>
</html>

최대한 책에 적힌 내용을 이해하고 테스트도 병행하는 중이지만 chapter 8에서 조금 막히는 점이 있어 질문을 드리게 되었습니다. 긴 글 읽어주셔서 감사합니다.