studybook
  • Introduction
  • 실무 하며 깨닫는 부분 정리
    • 옵션에 대해서
    • 코드 작성의 순서
    • 자바 프로그램에 문제가 생겼다면
    • 장애 대처법
  • Logstash, Beats 정리
  • Zookeeper 정리
  • Message Queue 정리
    • RabbitMQ 삽질
  • Java 관련 정리
    • Java Primitive Wrapper class
    • Java NIO
    • Java8 Double colon operator
    • Effective Java
      • 4장
      • 5장
      • 6장 - Enum, Annotation
      • 7장 - Method
      • 8장 - 프로그래밍 일반
      • 9장 - Exception
    • Java8 Lambda expression
    • JDBC
    • Linux에서 WatchService 이상동작
  • Spring 관련 정리
    • Spring Bean init, destroy 순서
    • Spring Async Controller
    • Spring Executable jar 웹 개발 및 배포
    • Spring Boot Font 배포 에러
    • Spring AOP
      • Spring AOP로 모든 Request 로그 남기기
    • Spring Cache
    • Spring Cloud
      • Consul로 spring 설정 관리하기
    • Spring Test
      • Spring Test DirtiesContext
      • Spring Test MockBean, SpyBean
      • Spring Test Dynamic @Scheduled
    • Spring JDBC
    • Spring Validation
    • Spring Transaction Management
      • Spring with JTA 삽질
    • Spring에서 효율적으로 Static resource 관리하기
    • Zuul을 사용해서 Spring Reverse proxy 만들기
    • Spring Security
    • 스프링 어노테이션이 안 먹힐 때 의심해볼만한 것
    • Spring Data
    • Spring Webflux
      • Tobi 강연
  • 코드 리팩토링
    • 한번에 하나씩
  • 지속적 통합 (CI)
    • Jenkins pipeline 삽질기
  • Log Aggregator 정리
    • Flume 테스트
    • Fluentd 테스트
  • Web Socket 정리
  • Akka
    • Actor 모델
    • Supervision
  • IE 8 대응 정리
  • 함수형 프로그래밍
    • 모나드
  • Netty
    • Netty 기본 예제
    • Netty 주요 특징
    • Netty 부트스트랩
    • Netty 채널 파이프라인, 코덱
    • Netty 이벤트 모델
    • Netty 바이트 버퍼
  • 스칼라 관련 정리
    • Maven으로 컴파일하기
    • Scala def 괄호 여부의 차이
    • 스칼라 function, method 차이점
    • ScalaTest와 Spring 연동하기
    • Programming in Scala
  • J2S 컨퍼런스
  • Android
    • 테스트
    • NDK
  • DDOS
  • HTTP
  • HttpClient
  • Container
    • Image 개요
    • cri-o
    • kata containers
    • Open Container Initiative Image
    • Buildkit
  • Github pages
  • Static Website
  • Webhook
  • Service Discovery Tools
    • Etcd
    • Eureka
    • Consul
      • ACL
    • 비교
  • React
    • JSX
    • React Element
    • Components, Props
    • State, Lifecycle
    • Handling Event
    • Flux
  • Vagrant
    • SSH 접속
  • Linux
    • Systemd
    • Alternatives
  • Messaging protocols
    • XMPP
    • AMQP
  • Windows
    • Windows10 내장 우분투에 ssh 클라이언트로 접속하기
    • Windows10 Hyper-V와 Virtual Box가 충돌을 일으켰을 때
    • Hyper-V 기반 docker에서 Shared Drives 설정 실패할 때
    • 윈도우 개발환경 설정
    • Docker desktop 없이 docker 환경 세팅하기
    • UWP 앱을 항상 관리자권한으로 실행하는 바로가기 만들기
  • Spring camp 2017
    • Project Reactive
    • 이벤트 소싱
    • CQRS
  • Spring webflux
  • 리액티브 프로그래밍
  • Linux Settings
    • 홈서버 백업 및 복구기
    • 홈서버 트러블슈팅
  • Kubernetes
    • k3s 설치 및 삽질
    • pod resources
    • Argo workflow
    • 트러블 슈팅
      • Kubernetes namespace의 phase가 Terminating에서 멈춰있을 때
    • 쿠버네티스 마스터
    • Knative
    • Knative Pipeline
    • Aggrerated API server
    • Accessing the API
      • Authenticating
  • Sonarqube
  • HTTP/2
  • Go
    • Go Module
    • Go dependency injection
    • Go Error handling
    • Go in Action
      • 3장 패키지
      • 4장 배열, 슬라이스, 맵
      • 5장 GO의 타입 시스템
      • 6장 동시성
      • 7장 동시성 패턴
      • 8장 표준 라이브러리
      • 9장 테스트와 벤치마킹
    • Go Channel 사용법
  • Cloud Native
Powered by GitBook
On this page
  • 컴포넌트 종류
  • Build
  • 장점
  • 단점
  • 설치법
  • 컴포넌트
  • 인증
  • 사용 예시
  1. Kubernetes

Knative

knative는 주로 빌드, 배포에 관련된 쿠버네티스 미들웨어 확장 컴포넌트.

컴포넌트 종류

  1. Build: source에서 컨테이너까지 각종 빌드에 관련된 컴포넌트

  2. Eventing: 이벤트를 관리하고 전달해주는 컴포넌트

  3. Serving: 스케일링과 관련된 컴포넌트

Build

Knative Build는 operator pattern으로 동작. Build라는 커스텀 리소스를 생성하면 그 리소스의 spec을 가지고 Pod을 생성하여 build작업을 수행.

하나의 Build는 여러 steps를 가지며 각 steps는 하나의 Builder를 가짐. 여기서 각 step 하나 하나는 실제로 pod이 생성될 때 하나의 init-container로 생성됨.

Builder는 컨테이너 이미지. 하나의 step 전용으로 만들어도 되고 범용으로 만들어도 되고 원하는대로 자유롭게 작성 가능.

BuildTemplate, ClusterBuildTemplate 쓰면 반복적으로 사용되는 부분을 추출해서 사용 가능

source는 깃 저장소, 구글 클라우스 스토리지, 임의의 컨테이너 이미지 등이 될 수 있음.

Secret, ServiceAccount를 사용해서 repository 등에 대한 authentication 수행

nop, build-step-credential-initializer, build-step-git-soruce 등 초기화작업을 위한 init-container를 먼저 모두 수행한 다음 사용자의 step을 init-container로 만들어서 수행

장점

  • jenkins같은 기존 CI 툴에 비해서 상대적으로 가벼움

  • kubernetes native

  • credential, scm checkout과 같은 필수 기능 자체 탑재

  • 모든 init-container가 /builder/home , /workspace 를 공유하기 때문에 Builder 작성 용이

  • 사용하는 컨테이너 이미지들을 자체적으로 caching

단점

  • argo workflow에 비해서 상대적으로 부족한 편의 기능

  • 하나의 Build 에 source 한개만 허용

  • 하나의 Build 에 template 한개만 허용

설치법

$ kubectl apply --filename https://raw.githubusercontent.com/knative/serving/v0.2.2/third_party/config/build/release.yaml

위 명령어를 실행하면 knative-build namespace를 생성하고 거기에 아래와 같은 리소스를 생성.

  1. ETC: cluster role, cluster role binding, serviceaccount, service, configmaps 등

  2. CRDs: Build, BuildTemplate, ClusterBuildTemplate, Image

  3. Deployments and Services: build-controller, build-webhook

컴포넌트

Build

  • spec: template이나 steps가 적어도 하나는 있어야함

    • steps : 하나의 빌드 단계. 빌드용 이미지와 argument로 정의.

      • array

        • name

        • image

        • args

    • template: 빌드 템플릿을 사용하는 단계. 빌드 템플릿 이름과 빌드 템플릿에 정의된 argument 전달

      • name

      • arguments

    • source: steps에 데이터를 전달하기 위해서 사용. source에 정의한 데이터는 /workspace 아래로 마운트됨.

      • git

        • url

        • revision

      • gcs

      • custom

    • serviceAccountName: 인증을 위해서 사용. 만약에 별도로 정의하지 않으면 네임스페이스의 default service account 사용

    • volumes

    • timeout

BuildTemplate

  • spec

    • parameters: step에서 사용할 수 있는 parameter 정의

      • array

        • name

        • description

        • default

    • steps: Build 의 steps와 동일. 차이점은 parameters에서 정의한 값을 ${NAME} 으로 사용 가능

Builder

Build 또는 BuildTemplate 의 steps의 image에 들어가는 값

  • Typical builders: 특정한 도구를 쓸 목적으로 만드는 빌더 이미지. entrypoint 또는 command에 해당 도구를 실행하는 명령어를 등록하고 args만 받아서 step 실행. 성공적으로 실행하면 zero status를 반환.

  • Atypical builders: 임의의 이미지를 빌더로 쓰는 케이스. command랑 args를 오버라이딩해서 사용.

빌더는 /workspace 를 기본 working directory로 가져야 함. 이 디렉토리는 knative build의 source 에 의해서 채워지고 steps 사이에서 공유됨

/builder/home 은 $HOME 으로 노출되어야 함.

service account에 붙어있는 credentials를 git 또는 docker credentials로 바꿔서 노출해야됨.

인증

kubernetes secret type 두 가지 지원

  • kubernetes.io/basic-auth

  • kubernetes.io/ssh-auth

이 두 가지 type의 secret를 service account에 붙이고 그 service account name으로 인증 절차 수행

secret에 annotation build.knative.dev/<git or docker>-<index>: <host name> 을 붙여서 어디 언제 사용할지 결정.

ssh-auth를 쓸 경우 주의할 부분이 몇가지 있는데 문서에서는

apiVersion: v1
kind: Secret
metadata:
  name: ssh-key
  annotations:
    build.knative.dev/git-0: https://github.com # Described below
type: kubernetes.io/ssh-auth
data:
  ssh-privatekey: <base64 encoded>
  # This is non-standard, but its use is encouraged to make this more secure.
  known_hosts: <base64 encoded>

위와 같이 어노테이션의 호스트에 https가 붙어있는데 이걸 붙이면 정상작동하지 않음.

그리고 Build 의 source 필드를 넣을 때 url도 https가 아니라 git@<registry url>:<organization>/<path>.git 형식으로 넣어야 함.

사용 예시

1. secret, service account, cluster role binding 생성

private registry를 쓴다면 annotation에 host를 넣고 필요한 인증정보를 secret으로 생성

apiVersion: v1
kind: Secret
metadata:
  name: knative-secrets-oss
  namespace: ncc-bd  
  annotations:
    build.knative.dev/git-0: oss.navercorp.com
type: kubernetes.io/ssh-auth
data:
  ssh-privatekey: <deploy key>
  known_hosts: <ssh known hosts>

---

apiVersion: v1
kind: Secret
metadata:
  name: knative-secrets-registry
  namespace: ncc-bd  
  annotations:
    build.knative.dev/docker-0: registry.navercorp.com
type: kubernetes.io/basic-auth
stringData:
  username: <user name>
  password: <user password>

---

apiVersion: v1
kind: ServiceAccount
metadata: 
  name: knative-service-account
  namespace: ncc-bd
secrets:
  - name: knative-secrets-oss
  - name: knative-secrets-registry

---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: knative-service-account
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: knative-service-account
  namespace: ncc-bd

2. BuildTemplate 생성

바로 Build를 만드는 것 보다 BuildTemplate을 만들고 Build에서는 필요한 패러미터만 채워주는 형식으로 만드는 편이 유리한듯.

아래 yaml은 전체 클러스터에서 사용할 BuildTemplate이므로 ClusterBuildTemplate으로 생성

apiVersion: build.knative.dev/v1alpha1
kind: ClusterBuildTemplate
metadata:
  name: init-namespace
spec:
  parameters:
  - name: NAMESPACE
    description: The name of target namespace
  - name: PASTA_SERVICE_ID
    description: The id of target pasta service
  - name: CEPH_CLASSNAME
    description: rbd-ssd | rbd-hdd
    default: rbd-hdd
  - name: CEPH_STORAGE
    default: 300Gi
  - name: PROMETHEUS_REPLICA_NUM
    description: number of pods
    default: "1"
  - name: OPENSTACK_ENVIRONMENT
    default: dev
  - name: GRAFANA_API_URL
  - name: GRAFANA_AUTH_TOKEN
  - name: GRAFANA_REQUEST_BODY

  steps:
    - name: pre-install
      image: base.registry.navercorp.com/ubuntu:18.04
      command: ["/bin/bash", "-c"]
      args: 
        - "curl -X POST -d '{\"openstack_environment\":\"${OPENSTACK_ENVIRONMENT}\", \"projectid\":\"${PASTA_SERVICE_ID}\", \"gigabytes\":\"+1000\",\"volumes\":\"+10\"}' -H 'Content-Type: application/json' -H 'Authorization: Basic MTM1ZjMwNTktOWI2ZC00ZmM3LWIwZGEtYmU1YTY2NzY5OWVmOjl1MmlZWXNHdVZJamExNUZhYjdvZ3REZWZEcWhESHRsaWdPelNHZGl4NjdGOVp6MFYwdE1RUGtVaHlreXU4VVg=' 'https://lambda-real.navercorp.com/api/v1/namespaces/operations/actions/operations/set_quota?blocking=true&result=true';"
    - name: install-prometheus
      image: registry.navercorp.com/ncc/ncc:v0.1.1
      workingDir: "/workspace/incubator/ncc-monitoring"
      command: ["/bin/bash", "-c"]
      args: 
        - ncc cluster use-in-cluster ${NAMESPACE};
          kubectl delete configmap -n ${NAMESPACE} container-dashboards --ignore-not-found=true;
          kubectl create configmap -n ${NAMESPACE} --from-file=grafana-templates/Containers_Detail.json --from-file=grafana-templates/Containers.json --from-file=grafana-templates/Deployments.json --from-file=grafana-templates/L4_LoadBalancer.json --from-file=grafana-templates/L7_Traefik.json --from-file=grafana-templates/Pod_Autoscaler.json container-dashboards;
          ncc helm list --namespace=${NAMESPACE};
          ncc helm install --namespace=${NAMESPACE} . --name=ncc-monitoring --replace --set server.namespace=${NAMESPACE} --set pasta.serviceid=${PASTA_SERVICE_ID} --set ceph.storage=${CEPH_STORAGE} --set server.replicas=${PROMETHEUS_REPLICA_NUM} --set ceph.classname=${CEPH_CLASSNAME}
    - name: install-grafana
      image: registry.navercorp.com/ncc/builds/grafana-builder:v0.0.3
      args: ["grafana-builder", "-u", "${GRAFANA_API_URL}", "-t", "${GRAFANA_AUTH_TOKEN}", "-b", "${GRAFANA_REQUEST_BODY}"]
    - name: post-install-grafana
      image: registry.navercorp.com/ncc/ncc:v0.1.1
      command: ["/bin/bash", "-c"]
      args:
        - ls -al;
          kubectl annotate --overwrite=true namespace ${NAMESPACE} ncc.navercorp.com/grafana-id=$(cat /workspace/grafana-id);
          kubectl annotate --overwrite=true namespace ${NAMESPACE} ncc.navercorp.com/grafana-url=$(cat /workspace/grafana-url);

3. Build 생성

apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
  name: namespace-initialization
  namespace: ncc-bd
spec:
  serviceAccountName: knative-service-account
  source:
    git:
      revision: master
      url: <git url>
  template:
    name: init-namespace
    kind: ClusterBuildTemplate # ClusterBuildTemplate인 경우에만 필요
    arguments:
      - name: NAMESPACE
        value: <value>
      - name: PASTA_SERVICE_ID
        value: <value>
      - name: CEPH_CLASSNAME
        value: <value>
      - name: GRAFANA_API_URL
        value: <value>
      - name: GRAFANA_AUTH_TOKEN
        value: <value>
      - name: GRAFANA_REQUEST_BODY
        value: <value>
  timeout: 10m0s

Previous쿠버네티스 마스터NextKnative Pipeline

Last updated 6 years ago