Skip to content

태그: 실습

총 18개의 글이 있습니다.

mnist 알파벳 데이터를 식별하는 CNN 모델 예제이다. python import tensorflow as tf import numpy as np import matplotlib.pylab as plt (train_images, train_labels), (test_images, test_labels) = tf.keras.datasets.mnist.load_data() plt.figure(figsize=(6,1)) for i in range(36): plt.subplot(3,12,i+1) plt.imshow(train_images[i], cmap="gray") plt.axis("off") plt.show() 28 * 28의 벡터 이미지 60000개, 채널은 1개 train_im

MNIST 숫자 판별

python import tensorflow as tf import numpy as np import matplotlib.pylab as plt (train_images, train_labels), (test_images, test_labels) = tf.keras.datasets.mnist.load_data() plt.figure(figsize=(6,1)) for i in range(36): plt.subplot(3,12,i+1) plt.imshow(train_images[i], cmap="gray") plt.axis("off") plt.show() train_images = train_images.reshape((60000, 28*28)) test_images = test_ima

배, 자동차, 비행기 분류하기

python import numpy as np import tensorflow as tf x = np.array([[0,0], [1,0], [1,1], [0,0], [0,0], [0,1]]) 바퀴, 날개 y = np.array([ [1,0,0], 배 [0,1,0], 자동차 [0,0,1], 비행기 [1,0,0], [1,0,0], [0,0,1] ]) model = tf.keras.Sequential() model.add(tf.keras.layers.Dense(input_dim=2, units=10, activation='relu')) input_dim : 입력값 갯수 model.add(tf.keras.layers.Dense(units=5, activation='relu'

10 most common mistakes using kubernetes

1. resources requests와 limits CPU request는 보통 설정하지 않거나 매우 낮게 설정하여(각 노드에 많은 Pod를 배치하기 위해) 노드가 오버커밋 상태가 된다. 높은 부하 시 노드의 CPU가 완전히 사용되면 워크로드는 "요청한 만큼"만 받게 되어 CPU 쓰로틀링이 발생하고, 애플리케이션 레이턴시 증가, 타임아웃 등의 문제가 생긴다. 반면 CPU limit은 노드의 CPU가 완전히 사용되지 않더라도 Pod를 불필요하게 쓰로틀링하여 레이턴시를 증가시킬 수 있다. Linux 커널의 CPU CFS 할당량과 설정된 CPU limit 기반 쓰로틀링, CFS 할당량 비활성화에 대한 논의가 진행 중이다. CPU limit은 해결하는 것보다 더 많은 문제를 일으킬 수

k8s에서 kubectl과 같은 커맨드를 사용해 API를 요청하는 과정은 크게 3가지로 구성되어 있다. 1. 'k8s 사용자가 맞느냐'를 판단하는 Authentication 2. 두 번째는 'API를 호출할 수 있는 권한이 있느냐'를 판단하는 Authorization 3. 마지막으로 그 요청이 적절한지를 판단하는 Admission Controller이다. Authorization와 Admission Controller는 k8s에 내장되어 있는 기능이기 때문에 사용 방법이 비교적 정해져 있는 반면, 첫 번째 단계인 Authentication은 이렇다 할 정답이 딱히 정해져 있지 않다. 물론 k8s의 자체 인증 기능인 ServiceAccount, 인증서 등을 사용할 수는 있지만, 사내에서 LADP, Go

k8s 클러스터 root CA를 통한 사용자 인증

k8s는 기본적으로 root CA 인증서를 스스로 발급해 사용한다. 이 인증서를 이용하면 별도의 Third-party 연동 없이도 User와 Group을 사용할 수 있다. 단, 이 방법은 여러모로 한계점이 많기 때문에 가능하면 사용하지 않는 것이 좋다. 인증서가 유출되었을 때 revoke가 힘들기도 하고, 파일 단위로 인증 정보를 관리하는 것은 매우 비효율적이고 보안에 취약하기 때문이다. 따라서 k8s는 인증서 발급을 통한 사용자 인증은 극히 제한된 경우에만 사용하고 있다. 대표적으로는 관리자 권한을 가져야 하는 `system:master` 그룹의 인증 정보를 생성한다거나 (`/etc/kubernetes/admin.conf`), k8s의 핵심 컴포넌트에 인증서를 발급한다거나 할 때가 이에 해당한다. 우선

OIDC Authentication with Dex

OIDC (Open ID Connect) 인증 방법은 OAuth2 위에서 동작하는 인증으로, Github이나 Google과 같이 서드 파티에서 부여받은 OAuth 권한을 통해 쿠버네티스의 인증을 수행한다. 기존에 사용하던 OAuth 인증 방법을 쿠버네티스에 그대로 가져온다고 생각하면 이해하기 쉽다. OIDC 인증 방법은 OAuth + JWT 토큰을 사용한다는 점에서 Webhook Token 인증 방법과 차이점을 갖는다. OAuth 토큰을 관리하기 위한 중간 서버를 구현한 [Dex]( 사용하여 OIDC 인증을 구현해보자. Dex Concept Dex는 서드 파티로부터 OAuth 인증 토큰을 가져와 관리하는 인증 도구이다. OAuth를 사용하기 위

Security Context for a Pod or Container

A security context defines privilege and access control settings for a Pod or Container. Security context settings include, but are not limited to: Descretionary Access Control: Permission to access an object, like a file, is based on user ID (UID) and group ID (GID)](

Token Webhook with Guard

Webhook 서버에 인증 데이터를 전달한 뒤, 클라이언트가 유효한지 인증하여 Third party에 권한을 부여하는 Webhook Token 인증 방법에 대해 알아보자. 1. 사용자는 미리 인증 데이터를 발급받아 놓고, 2. 사용자가 인증 데이터를 Bearer 헤더에 담아서 REST API 요청을 보내면 3. API 서버는 클라이언트가 유효한지를 검증하기 위해 Webhook 서버에 인증 데이터를 전달한다. 4. Webhook 서버는 해당 데이터를 검사한 뒤, 인증 여부를 API 서버에 반환하는 간단한 방식으로 되어 있다 Token Webhook, OIDC 중 어느 방법을 선택하든지에 상관 없이 클라이언트는 HTTP의 Bearer 헤더에 인증 데이터를 담아서 보내기만 하면 된다. 클라이언트는 인증

kubernetes 에서 ingress 상에서 https를 서비스하는데 지원을 해주는 모듈이다. cert manager 설치 bash kubectl create namespace cert-manager kubectl apply --validate=false -f or kubectl apply --validate=false -f kubectl create namespace cert

Let's set up role-based access control (RBAC) suitable for running the cluster in production. We will cover roles for using Calico. General RBAC for a production Kubernetes cluster is beyond the scope of this lab. Using `calicoctl` In order for the `calicoctl` tool to perform version mismatch verification (to make sure the versions for both the cluster and `calicoctl` are the same), whoever is

K8s를 위한 SpringBoot 개발

참고: Dockerize Spring Boot Application을 dockerize 하는 방법은 대표적으로 Jib, Buildpacks, Dockerfile 세가지가 있다. 이 중 Jib는 build time이 빠르고 (효율적인 layering), image 사이즈를 가장 작세 만들 수 있다는 장점을 가지고있다. Jib의 사용법은 간단하다. 아래와 같이 `build.gradle`에 jib gradle plugin을 추가하면 된다. groovy plugins { id 'com.google.cloud.tools.jib' version '3.2.0' } 그

kubectl context

쿠버네티스 클러스터를 관리하는 cli 도구인 kubectl에는 환경을 바꿔가며 클러스터를 관리할 수 있도록 "context"라는 개념이 존재한다. context 는 kubectl 을 깔면 생성되는 파일인 `~/.kube/config` 파일에서 설정할 수 있다. yml apiVersion: v1 clusters: cluster: insecure-skip-tls-verify: true server: name: local-cluster cluster: certificate-authority-data: ~~~~ server: name: gcp-cluster users: name: loca

minukube 시작하기

1. kubectl을 설치한다. 버전은 1.22로 통일한다. linux 기준 명령어는 다음과 같다. bash curl -o kubectl mac 기준 명령어는 다음과 같다. bash curl -o kubectl window 기준 명령어는 다음과 같다. bash curl -o kubectl.exe

NetworkPolicy Cilium example

Using the same KIND cluster from the Cilium install, let's deploy the Postgres database([database.yaml]( with the follwing `YAML` and `kubectl` bash $ kubectl apply -f database.yaml service/postgres created configmap/postgres-config created statefulset.apps/postgres created Here we deploy our web se

Pulling images from ECR on Kubernetes

If you are getting the HTTP 403 (Forbidden) error or the error message no basic auth credentials when trying to pull an image from ECR you are most likely doing so without logging into it first. This is going to happen if we are running a Kubernetes cluster on EC2 instances instead of using EKS. To be able to authenticate before pulling images on Kubernetes we need to use the imagePullSecrets att

SpringBoot 서비스를 위한 Kubernetes 설정

출처: Deployment 아래는 deployment설정의 예시이다. yml apiVersion: apps/v1 kind: Deployment metadata: name: main-server labels: app: main-server spec: selector: matchLabels: app: main-server template: metadata: labels: app: main-server spec: affinity: podAntiAffinity: preferr

환경변수 설정

포드의 구성 파일 안에서 정의한 환경 변수는 파드의 컨테이너를 위해 설정하는 커맨드와 인자들과 같이, 구성 파일 안의 다른 곳에서 사용할 수 있다. 아래의 구성 파일 예시에서, GREETING, HONORIFIC, 그리고 NAME 환경 변수들이 각각 Warm greetings to, The Most honorable, 그리고 Kubernetes로 설정되어 있다. 이 환경 변수들은 이후 env-print-demo 컨테이너에 전달되어 CLI 인자에서 사용된다. yml apiVersion: v1 kind: Pod metadata: name: print-greeting spec: containers: name: env-print-demo image: bash env: name